Jet 2.0 dB corruption under Vista

[V Green]

Old VB 3.0 app using Jet 2.0 engine runs fine
under very OS from 3.1 to XP but hangs then
corrupts DB under Vista Home Premium.

All running locally - not network shared, so that
KB article doesn't apply (seems to be for 4.0
anyway).

Any thoughts or is this the final nail in the coffin
for Vista? It came pre-installed on the laptop, and
I've had just about enough of the problems caused
by this OS and might upgrade to XP...

 

[Tom van Stiphout]

Old VB 3.0 app using Jet 2.0 engine runs fine
under very OS from 3.1 to XP but hangs then
corrupts DB under Vista Home Premium.

All running locally - not network shared, so that
KB article doesn't apply (seems to be for 4.0
anyway).

Any thoughts or is this the final nail in the coffin
for Vista? It came pre-installed on the laptop, and
I've had just about enough of the problems caused
by this OS and might upgrade to XP...

 

[Tom van Stiphout]

On Wed, 16 Jan 2008 20:31:31 -0700, "V Green" <[email protected]>
wrote:

After VB3 we got VB4, VB5, VB6, VB.NET 1.0, VB.NET 1.1, VB.NET 2.0
After Access 2.0 we got 95, 97, 2000, XP, 2003, 2007
Seems to me you got your money's worth out of the old app, and an
upgrade/rewrite might be in order. You've had about 10 years to save
up for it.

-Tom.

 

[Arvin Meyer [MVP]]

Are you sure that the problem is being caused by Jet and not VB 3.0?

Also, is the laptop/Vista 32 bit or 64 bit? It might be a bit of a stretch
to think that a 16 bit program would run on a 64 bit machine.

 

[V Green]

After VB3 we got VB4, VB5, VB6, VB.NET 1.0, VB.NET 1.1, VB.NET 2.0
After Access 2.0 we got 95, 97, 2000, XP, 2003, 2007
Seems to me you got your money's worth out of the old app, and an
upgrade/rewrite might be in order. You've had about 10 years to save
up for it.

-Tom.

Don't wanna. No time, should not be necessary - got other things to do- app
works
FINE on any other OS but this one. I should not have to port it just to run
on this POS.

 

[V Green]

Are you sure that the problem is being caused by Jet and not VB 3.0?

No way to tell that I'm aware of. Other VB 3.0 apps work OK though
except for the "embedded icon" malfunction that's no big deal.

Also, is the laptop/Vista 32 bit or 64 bit? It might be a bit of a stretch
to think that a 16 bit program would run on a 64 bit machine.

32 bit.

 

[Tom van Stiphout]

I just think it's asking too much of MSFT to be backward compatible in
perpetuity.
If you continue to run the hardware and OS that was en vogue in the
VB3/A2 days you should continue to have no difficulties. Other than a
Y2K problem, perhaps. I believe that hardware was a 486 with 8MB of
RAM, and Windows 3.0

-Tom.

 

[Tony Toews [MVP]]

It came pre-installed on the laptop, and
I've had just about enough of the problems caused
by this OS and might upgrade to XP...

FWIW double check that your vendor has Win XP drivers for your laptop.
You may not be able to "upgrade"/"downgrade"/whatever to XP.

Tony

--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[david]

Does Vista have compatibility mode? Can you try
running it in a Win95 compatibility mode?

Are you sure it's installed correctly (Jet 2.5 compatibility layer?)

Are you running any Jet 4.0 processes on the database?

Too bad they don't have a win16 compatibility mode -- Jet
2.x flushed transactions to disk, but that was broken by the
Win32 file system.

(david)

 

[V Green]

David, thanks.

I had completely forgotten about the COMLAYER
issue, I haven't applied that yet.

I'll give it a go...

 

[V Green]

Moved the VB editor over to the Vista machine to
figure this out.

You won't believe what it was.

I had the Regional Settings for Short Date in Control Panel
set to:

MM/dd/yyyy

Part of the offending program used a date search
based on the format:

M/d/yyyy

so that when the search ran, it of course could not find a
date string that matched the current date because it had a
0 prepended to it (01/17/2008) instead of (1/17/2008).

The field in the db that I was searching on is of type
Date/Time and Short Date.

Duh (smacking self several times in forehead).

I remember setting my date to MM/dd/yyyy on the new Vista
laptop during setup - I don't remember doing it on all the other
machines this app has run on (probably because I didn't).

The db probably got corrupted during my attempts to end the
app (which was stuck in a loop, endlessly counting up in LONG
dates looking for a db match on a SHORT date field).

My apologies to all who offered assistance and to whom I was
rude.

Life goes on.

 

[Tony Toews [MVP]]

I had the Regional Settings for Short Date in Control Panel
set to:

MM/dd/yyyy

Part of the offending program used a date search
based on the format:

M/d/yyyy

so that when the search ran, it of course could not find a
date string that matched the current date because it had a
0 prepended to it (01/17/2008) instead of (1/17/2008).

The field in the db that I was searching on is of type
Date/Time and Short Date.

But that shouldn't matter. Unless you are doing string comparisons
and not numeric comparisons.

Internally Access and Jet stores date/time fields as a double number.
With the part to the left of the decimal point being a count of the
number of days since an epoch date and the right being the time. So
all you should be doing is comparing one number to another number.

And also this shouldn't be corrupting either. But if it works then it
works.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[V Green]

But that shouldn't matter. Unless you are doing string comparisons
and not numeric comparisons.

Internally Access and Jet stores date/time fields as a double number.
With the part to the left of the decimal point being a count of the
number of days since an epoch date and the right being the time. So
all you should be doing is comparing one number to another number.

I agree. I'm still looking at the code to see why. But I have a
workaround for now so I can take my time.

And also this shouldn't be corrupting either. But if it works then it
works.

I *think* that happened when I forced the app to close - not
sure. It doesn't happen every time.

 

[David W. Fenton]

Old VB 3.0 app using Jet 2.0 engine runs fine
under very OS from 3.1 to XP but hangs then
corrupts DB under Vista Home Premium.

All running locally - not network shared, so that
KB article doesn't apply (seems to be for 4.0
anyway).

Any thoughts or is this the final nail in the coffin
for Vista? It came pre-installed on the laptop, and
I've had just about enough of the problems caused
by this OS and might upgrade to XP...

Are you sure it's Jet 2.0? That was a very buggy Jet release, and
massively patched with the Jet 2.5 update. I had a client switch
from Win95 to Win2K with an Access 2.0 app and they forgot to apply
the Jet 2.5 patch, and they had massive problems until I got all
their machines patched to Jet 2.5.

You should look into whether or not that can be applied after the
fact. It might very well correct the problems.

 

[Fred]

Maybe I'm dumb enought to give a smart answer. Upgrade from Vista to XP.