Jump to content

New Database numbering format


Recommended Posts

  • Replies 55
  • Created
  • Last Reply

Top Posters In This Topic

"We will use the date in the UI still, this naming scheme gets more specific though. It tells you which number of database it is on a particular day, something the date info does not tell you."

I'm afraid I can't remember the update number I just performed. As I have always done, I update before each scan. Is there some reason I should actually pay attention to the number of the update I'm installing over an older update? All I ever do is look to see if the number of the available update is greater than the one that I'm overwriting.

The only reason I can imagine why this is important is if, somehow, an older update was replacing a newer one. I've never seen that happen. Wouldn't that be called a retro-update? (An anti-update? Actually, a downgrade?)

I'm not trying to start an argument, but it seems that you're hinting at something of which I'm not aware. Has MBAM actually sent out any old updates that are marked as new updates? I just don't get it.

I don't mind the change in the numbering system at all. I just see no need to overcomplicate it. Most of us can easily handle 9,999 changing to 10,000. It isn't like whenever the new Millenium started and no one knew for sure when that was. I saw the points brought up by both sides of that non-argument and decided I really didn't care. Neither the world, the internet, nor my computers self-destructed. Win-win, either way.

As long as the updates keep rolling along, this is also a non-issue. I wouldn't even have posted here if I was actually informed of the change and didn't have to come here to see if my copy of MBAM had been corrupted. You should've at least have informed your MBAM-Pro customers. For the people running the free version, WYSIWYG.

Link to post

"We will use the date in the UI still, this naming scheme gets more specific though. It tells you which number of database it is on a particular day, something the date info does not tell you."

I'm afraid I can't remember the update number I just performed. As I have always done, I update before each scan. Is there some reason I should actually pay attention to the number of the update I'm installing over an older update? All I ever do is look to see if the number of the available update is greater than the one that I'm overwriting.

The only reason I can imagine why this is important is if, somehow, an older update was replacing a newer one. I've never seen that happen. Wouldn't that be called a retro-update? (An anti-update? Actually, a downgrade?)

I'm not trying to start an argument, but it seems that you're hinting at something of which I'm not aware. Has MBAM actually sent out any old updates that are marked as new updates? I just don't get it.

I don't mind the change in the numbering system at all. I just see no need to overcomplicate it. Most of us can easily handle 9,999 changing to 10,000. It isn't like whenever the new Millenium started and no one knew for sure when that was. I saw the points brought up by both sides of that non-argument and decided I really didn't care. Neither the world, the internet, nor my computers self-destructed. Win-win, either way.

As long as the updates keep rolling along, this is also a non-issue. I wouldn't even have posted here if I was actually informed of the change and didn't have to come here to see if my copy of MBAM had been corrupted. You should've at least have informed your MBAM-Pro customers. For the people running the free version, WYSIWYG.

No downgrade has ever happened that I'm aware of. We made the change because it makes sense. The old numbering scheme was just a series of arbitrary numbers, so a user could never truly tell if their database was up to date or not, and neither could support personnel assisting them (note that the database version used for a scan is displayed in the header of each scan log). It's important information to have, and affects everything from helping to verify that a system is clean (if using an outdated database, something may have been missed) to ensuring false positives are corrected.

Link to post

No downgrade has ever happened that I'm aware of. We made the change because it makes sense. The old numbering scheme was just a series of arbitrary numbers, so a user could never truly tell if their database was up to date or not, and neither could support personnel assisting them (note that the database version used for a scan is displayed in the header of each scan log). It's important information to have, and affects everything from helping to verify that a system is clean (if using an outdated database, something may have been missed) to ensuring false positives are corrected.

I'm still not trying to argue with you.

Since the newest update you download completely replaces whatever you had prior to the new update, there is no possible way to know what update you may have had a problem with unless, of course, you report a problem with an update before checking for a new one.

I know of nobody who runs a scan BEFORE they download a new update that's waiting to be downloaded, so any problem will always be with the newest update, or the person would've already asked about a problem before they even checked for the next update.

The new numbering system only complicates what was a very easy way to check the number of a new update to the last update.

As far as numbering updates with random numbers, previously, I'll take it for granted you really don't mean that. Every single update I have ever performed had a number that was different from the prior update by just the last one or two decimals. The updates being generally, in series, from one to the the number of the last update. A completely non-random numerical sequence.

You believe that, for example, the date right now, 12/23/2011 plus the number of the present database version update (I just checked) 05, making it 12/23/2011 #05, is harder to comprehend than the seemingly random numbers you now use (911122205), which means exactly the same thing? If so, then I've awakened to an alternate universe with neither rhyme nor reason and I want to go home!

As I keep repeating, I'm not arguing. You can call the new updates "Pink Badger" for all I care. Just as long as a new update actually is "New"! Which is not as easy as before, regardless of what you say. Change, just for the sake of change, is completely illogical. You appear to have been tasked with a "Make Work" job as if you had nothing better to do. Nothing has been accomplished.

I'm completely happy with M-Bam or I would have never paid for the PRO version!

Link to post

Since the newest update you download completely replaces whatever you had prior to the new update, there is no possible way to know what update you may have had a problem with unless, of course, you report a problem with an update before checking for a new one.

I know of nobody who runs a scan BEFORE they download a new update that's waiting to be downloaded, so any problem will always be with the newest update, or the person would've already asked about a problem before they even checked for the next update.

That's not always the case, you must remember that the scan logs are saved automatically, so we can see when a scan was performed. Before, all we had were version numbers, being able to track down, for example, a false positive to a specific day could be very helpful, especially for our Research team.

The new numbering system only complicates what was a very easy way to check the number of a new update to the last update.

As far as numbering updates with random numbers, previously, I'll take it for granted you really don't mean that. Every single update I have ever performed had a number that was different from the prior update by just the last one or two decimals. The updates being generally, in series, from one to the the number of the last update. A completely non-random numerical sequence.

You believe that, for example, the date right now, 12/23/2011 plus the number of the present database version update (I just checked) 05, making it 12/23/2011 #05, is harder to comprehend than the seemingly random numbers you now use (911122205), which means exactly the same thing?

Our previous numbering scheme literally started at 1 and went all the way up to over 8000, it changed by far more than the last 2 decimals. Using a numbering scheme based on the date, and order of release for that specific date tells me a lot more than "8172", which just means it is the 8172nd database we've EVER released, and says absolutely nothing about WHEN the database was released.

As I keep repeating, I'm not arguing. You can call the new updates "Pink Badger" for all I care. Just as long as a new update actually is "New"! Which is not as easy as before, regardless of what you say. Change, just for the sake of change, is completely illogical. You appear to have been tasked with a "Make Work" job as if you had nothing better to do. Nothing has been accomplished.

I'm completely happy with M-Bam or I would have never paid for the PRO version!

It was not change for the sake of change, it was a change to make things far more logical, and was the decision of our developers, server admins and researchers to make all of their jobs easier and to help both our users and support staff. It allows you to look at the number of the database and know precisely when it was released. If you're used to reading 7###, 8### etc. for your database version (our previous numbering scheme), I can understand why this change might throw you for a loop at first, but the fact of the matter is, for anyone who hasn't been using MBAM for a very long time (and even many who have been), there's no way for them to know how old their database was with the old scheme.

For example, I can't tell you the day, or even year, that database 2568 was released, and can only tell you now that it is an old database because I know that our database reached over 8000 before we changed the numbering scheme. Had our new database numbering scheme been in place from the beginning, the number used in lieu of 2568 would have instead been the actual date of release, and I could tell you precisely when it was created instead of having to 'guess' that it was a really long time ago.

Link to post

That's not always the case, you must remember that the scan logs are saved automatically, so we can see when a scan was performed. Before, all we had were version numbers, being able to track down, for example, a false positive to a specific day could be very helpful, especially for our Research team.

Our previous numbering scheme literally started at 1 and went all the way up to over 8000, it changed by far more than the last 2 decimals. Using a numbering scheme based on the date, and order of release for that specific date tells me a lot more than "8172", which just means it is the 8172nd database we've EVER released, and says absolutely nothing about WHEN the database was released.

It was not change for the sake of change, it was a change to make things far more logical, and was the decision of our developers, server admins and researchers to make all of their jobs easier and to help both our users and support staff. It allows you to look at the number of the database and know precisely when it was released. If you're used to reading 7###, 8### etc. for your database version (our previous numbering scheme), I can understand why this change might throw you for a loop at first, but the fact of the matter is, for anyone who hasn't been using MBAM for a very long time (and even many who have been), there's no way for them to know how old their database was with the old scheme.

For example, I can't tell you the day, or even year, that database 2568 was released, and can only tell you now that it is an old database because I know that our database reached over 8000 before we changed the numbering scheme. Had our new database numbering scheme been in place from the beginning, the number used in lieu of 2568 would have instead been the actual date of release, and I could tell you precisely when it was created instead of having to 'guess' that it was a really long time ago.

One last question. I've clicked "NO Notifications" on this topic ever since I 1st posted and I keep getting e-mails saying I've been responded to. How do I get out of this endless, pointless debate? I don't agree with you and I never will. I just don't want to hear about it any longer. I followed the directions to opt out and they obviously don't work.

Link to post

Thanks for the work that you do here. I saw the new system and thought, "Wow how long has it really been since I updated?" LOL!!!

If I hadn't seen this post first, I would have thought the same thing :lol: :lol:

Link to post
If I hadn't seen this post first, I would have thought the same thing
:D :D

I think at some point I am going to need to just go and get the paid version myself. Maybe treat myself to a Christmas gift of it. :)

Link to post

Great work peeps - a nasty present for those makers of malware...

Merry Christmas and A Happy New Year to one and all at MBAM

You bet! I just want to report that yr. new update numbering system IS SELF-EXPLANATORY w/ 3 min.

of thought, and my V1.51.2.1300 works GREAT on Win7 Home Premium, internal M$ Ver. (build?)

No. 6.1.7601. AWESOME DETECTION POWER ON THE SCANS on my 3GHz, 1-terabyte HD 4 Gb. RAM

AMD chipset machine. Every tech I know refers me to Malwarebytes Scan as the FINAL authority

on seeing if any probs are caused by infections! EVERY SINGLE ONE! And I wrote my first line of

code in 1968 age 15, been on the Net since 1991 - taught myself just enough UNIX to get around

in several shells. Telnet, mailreader, FTP, and - Remember Gopher? I remember the time I first

started saw the refs to http:// and telltale www and thought: "I'm gonna have to get the wares

to use that new funky connecting app!" Little did I know! I'm broadbanded of course, but still

have my prestigious keep shell access and my User #1 addy at io.com (now prismnet.com) Only 776

of those 2-letter domains in .com!

MERRY CHRISTMAS, EXPERTS! THE MBAM BEST!

Link to post
Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.

Back to top
×
×
  • Create New...

Important Information

This site uses cookies - We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.