VFP8 ODBC Advantage 7.10 C0000005 error

[garyebs]

I am having a problem with VFP8 SP1 using stringconnect with Advantage ODBC V7.10 on XP Pro Dev system. It happens on a particular record in a complicated series of SQL accesses. However, usually it doesn't happen on the first access, only if you repeat the series. At first I thought it was different in IDE vs run as EXE, but it happens within a couple of trys in either mode. The error is reported by the "Advantage DB Server" (title of messagebox) with the follow message:

An exception occurred in the Advantage Local Server axCommReq function. This process will be stopped. The exception code is 0xC0000005. The base load address is 0x1E940000. The execption occurred at address 0x77e765F7

(yes, the second exception is spelled incorrectly in the message box).

I changed the values for sys(3050) for foreground and background sizes larger and smaller and it had no effect on the message. I also deleted the foxuser.*** files.

I have other programs that work fine that use the same advantage odbc connection methodologies that have been running in the field since 1999.

Any ideas ?

Thanks in advance.

 

[rgbean]

I think I'd start by seeing if there were any updates to the ODBC driver. Many times there will be changes made to the database itself that ODBC just can't handle. e.g. AutoInc fields and the VFP (6.0) ODBC driver.

Rick

 

[garyebs]

Good ideas. The 7.10.0.0 is the latest and only version for the 7.1 Major Release. We support several versions of the ADS database going back to 3.x. As long as the data was created with a version less than or equal to the ODBC version, everything has worked fine at several 100 installs with our original product line. The software I'm working on now is new (a 2nd product line) and it accesses the data differently and is only at 2 sites so far, so the code itself is not proven. I also noticed I was using data created with V 6.22, so I went back to 6.22 odbc driver and I got the same problem. However, it did not come up till the fourth try and it was on the 3rd record processed, but after that it was on the 12th record for all subsequent accesses, as it was with 7.10.

I'm thinking it's the way the SQL statement is being executed by the Advantage Data Base, so I'm looking into changing it to work differently and see if it "just goes away". I used more complicated queries with this product.

If you have any other ideas, let me know.

Thanks