Machine Specific Data Error

[dotnetprogrammer]

Have You Heard of Something Like This???
Please help me with your expert input!

Some software-users have been experiencing problem with a database related VB6 app. The app utilizes DAO, ADO, ODBC, Access MDB, etc.

The application returns SLIGHTLY different query results on some PCs.

Apparently, the problem is noticeable with older PCs (around Pentium 400MHz or less) including Notebooks.(compared under similar OS: Win9x, NT, Win2K etc.) making the result UNRELIABLE!
I could not figure out what causes this problem, CPU? May be? Please help!
fred

 

[petermeachem]

Using DAO and ADO in the same programme is not generally a good idea.
Give us a clue about the query. Do you use dates? Are you comparing real numbers? What different data is returned? Peter Meachem
peter@accuflight.com

 

[dotnetprogrammer]

Peter,
DAO and ADO mixture was due to a mix of many programmers work.
We are comparing integers and real numbers (currency format) as well as numbers in text format.
Thanks,
fred

 

[petermeachem]

Integers and currency should be ok I would think. What do you mean by numbers in terxt format. Can you give an actual example? Peter Meachem
peter@accuflight.com

 

[dotnetprogrammer]

Numbers in text format:
Stuffing numeric characters in field whose datatype is text.
Example:
Suppose, the datatype of field1 in tblMyTable is Text, and we store "12345" (without quotes) in it. Eventhough the value stored are numeric-characters, they are stored in the field as text-characters. It is required by the spec that I am dealing with.
Thanks

 

[petermeachem]

You have the same message in another thread. I think Chip and Nick have a possible answer. You said something about running hundreds of queries. Nick and I have had to put delays in between queries like this and I have see nthe same even on vb3 programmes. The query returns, but has actually not completed. I'm not quite sure what happens, but the rows in the database don't seem to get updated when they should have done. Waiting a second seems to fix it. Peter Meachem
peter@accuflight.com