JET 4.0 sp7 breaks old vba code!

[Eric Isaacs]

I've posted some questions on other threads on this topic,
but thought I should repost the answer to make it more
promenent. I've determined that JET 4.0 sp7 has broken
old code that I've been using for years.

Specifically, I'm getting Error 3001 - "Invalid Argument"
when doing a tabledefs.append and I've also determined
that it causes Error 3219 - "Invalid Operation" when doing
a querydefs.append. This is occuring with code that is
referencing DAO 3.6 at least.

There are a number of other posts I've seen in the
newsgroups that have been showing similar errors. No one
has specified in these posts if they have applied JET 4.0
sp7 or not.

I also understand from another post on the subject that
Windows 2000 sp4 includes the JET 4.0 sp7 patch. Applying
the Windows 2000 sp4 will break the same code. I have
applied the sp4 patch on my Win2k machine and the Win XP -
JET 4.0 sp4 patch to my two machines. Only after having
applied these patches did the code break. Before I
patched my xp machine, my code was working there and not
working on my Win2k machine that I had patched. Only
after applying the patch and rebooting did the problem
start to occur on my Win XP machine too.

If you have any control over your user's machines, I
wouldn't recommend updating to Win2k sp4 or JET 4.0 sp7
for the time being.

I'll post code for confirmation of this issue in a post
that will follow on this thread.

 

[Eric Isaacs]

I've heard through the grape vine that Windows 2000 SP4
contains JET 4.0 SP7. I have applied Win2K SP4 on my
Win2K machine and the problem exists on that machine. So
be warned that just avoiding JET SP7 may not avoid having
to deal with this issue.

 

[Eric Isaacs]

David,

I would hold off on sp4 or sp7 at this point, unless you
want to test this. It would be great to get another
person to confirm what I found. You should be able to run
that code now without any trouble on your machine.
If/when you apply sps, it should break at that point.

I tried using other options as well, such as dbAttachTable
(I think that was it, but memory is uncertain.) Anyway,
there are really only two options if you want the table to
attach (otherwise you're adding a new table to the db
without attaching it.) One is dbAttachSavePWD, the other
is dbAttachTable (or something similar.) Anyway, both
cause the same error, so attaching the table doesn't work
either way. Specifying zero likely wouldn't attach the
table.

I found a similar error when appending a querydef to the
querydefs collection too, so my hunch is that appending
any type of table would fail. I'm not looking forward to
fixing all my code that I have in many MDB files under
many different contracts because of the problems with this
sp. I haven't found a workaround yet, and I'm hoping I
won't have to, since it seems to be a service pack issue
that will likely have a fix soon, I hope.

Thanks for replying.

 

[david epsom dot com dot au]

either way. Specifying zero likely wouldn't attach

Eric, FWIW, the documentation is wrong or misleading
on these options: there are really 3 options if you
want a table to attach: Exclusive, SavePWD, or 0 (zero).
You can't use dbAttachTable (that is a read only
property), you can't leave the field blank (although
I found a kludge workaround for that!), you can
and should use 0 if you don't want to save the PWD
in the connect string (including if you are using
a trusted connection)

(david)