K
kiln
I started a thread called "AutoNumber uses less than greatest value!" on
Sept 11 the first time I ran into this problem. Several helpful posts
were made, most notably by Allen Browne, but the issue seems to remain.
I very much need to get a handle on this horrific new flaw in Access
that Microsoft has introduced. It is having a major ongoing impact on my
deployed databases and in my interest in this product. Microsoft seems
to be behaving in a completely irresponsible manner about this bug, by
virtue of their scant attention and useless, defective and destructive
patches. I need to hear from peer developers on the issue.
Allan Browne has a write up of at least part of the issue at
http://allenbrowne.com/ser-40.html
A partial fix is offered there (thanks Allan!).
Microsoft has related KB articles at
http://support.microsoft.com/?kbid=287756
and
http://support.microsoft.com/?id=257408
According to both Allan and the KB article, this issue is fixed by Jet 4
sp7. Jet 4 sp7 was installed on my machine in the Windows 2000 sp4
patch. Jet 4 sp7 is Msjet40.dll ver 4.0.7328.0 size 1,507,600, and that
is the file installed on my machine by Win2k sp4. However, the Jet sp7
"fix" does not work for me, I still get Autonumber anomolies. Even the
fix offered by Allan that moves the seed value is temporal, ie it only
works till the next time I compact and append to a table.
Example: I have a table with a PK set to Autonumber Long Increment. I
delete all the records in it and compact. If I try to enter a new record
it gets a PK value of 1. Fine. I append about 28k records to it from
another table; the highest value in the table is now 286843. If I try to
enter a new record, Jet will try to assign a PK value of 272102. If I
use Allen's code fix, the seed is reset properly to 286844. New data
entry can proceed. But if the data is deleted from the table and data
reappended, the issue reappears. In other words, the improper seed value
is reinstated somehow. The fix offered by Allan is only good for one
delete-append-AutoNumFix() cycle. While helpful, it is not the same as a
real fix. (note: the db that I'm working with needs to work with this
delete-append cycle because it is in beta testing and legacy data must
be deleted and reimported each week as testing goes on).
Questions:
[1] What is the origin of this bug? Jet sp6?
[2] Why is Jet sp7 promoted as a fix when it isn't (Q257408 says >= Jet
4 sp4 will fix it!)?
[3] Why isn't a real fix for this of the highest priority for Microsoft?
[4] When can a proper fix be expected?
Access has had more than it's share of bugs over the years. I think this
bug is the most serious I can remember. I will not be able to continue
with this platform unless Microsoft gets off their duff and fixes it.
Whoever introduced this bug into Access should be out of a job and back
to work on the line at Burger King where they apparently came from.
Can't a company the size of Microsoft spare one quality programmer for a
tool that in wide use on a worldwide basis?
I have posted this to three newsgroups as it appears to me to be of
extreme importance. Office 2000 is at sp3 on this machine.
Sept 11 the first time I ran into this problem. Several helpful posts
were made, most notably by Allen Browne, but the issue seems to remain.
I very much need to get a handle on this horrific new flaw in Access
that Microsoft has introduced. It is having a major ongoing impact on my
deployed databases and in my interest in this product. Microsoft seems
to be behaving in a completely irresponsible manner about this bug, by
virtue of their scant attention and useless, defective and destructive
patches. I need to hear from peer developers on the issue.
Allan Browne has a write up of at least part of the issue at
http://allenbrowne.com/ser-40.html
A partial fix is offered there (thanks Allan!).
Microsoft has related KB articles at
http://support.microsoft.com/?kbid=287756
and
http://support.microsoft.com/?id=257408
According to both Allan and the KB article, this issue is fixed by Jet 4
sp7. Jet 4 sp7 was installed on my machine in the Windows 2000 sp4
patch. Jet 4 sp7 is Msjet40.dll ver 4.0.7328.0 size 1,507,600, and that
is the file installed on my machine by Win2k sp4. However, the Jet sp7
"fix" does not work for me, I still get Autonumber anomolies. Even the
fix offered by Allan that moves the seed value is temporal, ie it only
works till the next time I compact and append to a table.
Example: I have a table with a PK set to Autonumber Long Increment. I
delete all the records in it and compact. If I try to enter a new record
it gets a PK value of 1. Fine. I append about 28k records to it from
another table; the highest value in the table is now 286843. If I try to
enter a new record, Jet will try to assign a PK value of 272102. If I
use Allen's code fix, the seed is reset properly to 286844. New data
entry can proceed. But if the data is deleted from the table and data
reappended, the issue reappears. In other words, the improper seed value
is reinstated somehow. The fix offered by Allan is only good for one
delete-append-AutoNumFix() cycle. While helpful, it is not the same as a
real fix. (note: the db that I'm working with needs to work with this
delete-append cycle because it is in beta testing and legacy data must
be deleted and reimported each week as testing goes on).
Questions:
[1] What is the origin of this bug? Jet sp6?
[2] Why is Jet sp7 promoted as a fix when it isn't (Q257408 says >= Jet
4 sp4 will fix it!)?
[3] Why isn't a real fix for this of the highest priority for Microsoft?
[4] When can a proper fix be expected?
Access has had more than it's share of bugs over the years. I think this
bug is the most serious I can remember. I will not be able to continue
with this platform unless Microsoft gets off their duff and fixes it.
Whoever introduced this bug into Access should be out of a job and back
to work on the line at Burger King where they apparently came from.
Can't a company the size of Microsoft spare one quality programmer for a
tool that in wide use on a worldwide basis?
I have posted this to three newsgroups as it appears to me to be of
extreme importance. Office 2000 is at sp3 on this machine.