Counting records in a dBase III file
-
I'm interacting with a dBase III file using Microsoft's ODBC dBase driver. I can create a
CRecordsetobject and iterate through the table just fine (populating controls on a dialog and such). When I went to count the rows/records in the table usingSELECT COUNT(*) FROM ACTY, the code kept throwing exceptions. Based on the error messages in the debug window, I suspected column 1 (type Date) was at fault. I managed to insert another column into the table of type Text (Numeric type also works). The COUNTing code now works fine. My question is, why? I could iterate the table just fine when the first column was a Date, but not count the rows. Is there a rule that states what types can be in the first column and what types cannot when counting? As there are hundreds of these database files in use, injecting a "dummy" column into them just for the sake of counting is not a solution. [edit] I was able to create a dBase 5 table and it exhibited the same behavior. When I added the extra column, however, no exceptions and counting worked fine. [/edit] [edit2] I was able to successfully count records in the table using the ODBC API (e.g.,SQLDriverConnect(),SQLExecDirect(),SQLGetData()) rather thanCDatabaseandCRecordset. [/edit2]"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
-
I'm interacting with a dBase III file using Microsoft's ODBC dBase driver. I can create a
CRecordsetobject and iterate through the table just fine (populating controls on a dialog and such). When I went to count the rows/records in the table usingSELECT COUNT(*) FROM ACTY, the code kept throwing exceptions. Based on the error messages in the debug window, I suspected column 1 (type Date) was at fault. I managed to insert another column into the table of type Text (Numeric type also works). The COUNTing code now works fine. My question is, why? I could iterate the table just fine when the first column was a Date, but not count the rows. Is there a rule that states what types can be in the first column and what types cannot when counting? As there are hundreds of these database files in use, injecting a "dummy" column into them just for the sake of counting is not a solution. [edit] I was able to create a dBase 5 table and it exhibited the same behavior. When I added the extra column, however, no exceptions and counting worked fine. [/edit] [edit2] I was able to successfully count records in the table using the ODBC API (e.g.,SQLDriverConnect(),SQLExecDirect(),SQLGetData()) rather thanCDatabaseandCRecordset. [/edit2]"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
I'm surprised at your findings. The COUNT function shouldn't care what columns are on the table or what datatype they're made of. May be a bug with the driver? If I were you, I would suspected that USER was a keyword and would have tried to rename the table and see if it worked instead of adding a new column.
-
I'm interacting with a dBase III file using Microsoft's ODBC dBase driver. I can create a
CRecordsetobject and iterate through the table just fine (populating controls on a dialog and such). When I went to count the rows/records in the table usingSELECT COUNT(*) FROM ACTY, the code kept throwing exceptions. Based on the error messages in the debug window, I suspected column 1 (type Date) was at fault. I managed to insert another column into the table of type Text (Numeric type also works). The COUNTing code now works fine. My question is, why? I could iterate the table just fine when the first column was a Date, but not count the rows. Is there a rule that states what types can be in the first column and what types cannot when counting? As there are hundreds of these database files in use, injecting a "dummy" column into them just for the sake of counting is not a solution. [edit] I was able to create a dBase 5 table and it exhibited the same behavior. When I added the extra column, however, no exceptions and counting worked fine. [/edit] [edit2] I was able to successfully count records in the table using the ODBC API (e.g.,SQLDriverConnect(),SQLExecDirect(),SQLGetData()) rather thanCDatabaseandCRecordset. [/edit2]"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
-
DavidCrow wrote:
dBase III
:wtf: I do hope that you have a copy of that database is a more recent format?
Bastard Programmer from Hell :suss:
If I can't operate on it directly, I will consider converting it. Given the constraints on the client side, that would be a last resort.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
-
I'm surprised at your findings. The COUNT function shouldn't care what columns are on the table or what datatype they're made of. May be a bug with the driver? If I were you, I would suspected that USER was a keyword and would have tried to rename the table and see if it worked instead of adding a new column.
Shameel wrote:
I'm surprised at your findings. The COUNT function shouldn't care what columns are on the table or what datatype they're made of. May be a bug with the driver?
I'm not familar enough with it one way or the other. If you step through the code, however, the columns are definitely being bound (in the set's
DoFieldExchange()method).Shameel wrote:
If I were you, I would suspected that USER was a keyword and would have tried to rename the table and see if it worked instead of adding a new column.
There are actually two tables: ACTY and USER. The USER table works fine with no changes, both iterating and counting.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
-
I'm interacting with a dBase III file using Microsoft's ODBC dBase driver. I can create a
CRecordsetobject and iterate through the table just fine (populating controls on a dialog and such). When I went to count the rows/records in the table usingSELECT COUNT(*) FROM ACTY, the code kept throwing exceptions. Based on the error messages in the debug window, I suspected column 1 (type Date) was at fault. I managed to insert another column into the table of type Text (Numeric type also works). The COUNTing code now works fine. My question is, why? I could iterate the table just fine when the first column was a Date, but not count the rows. Is there a rule that states what types can be in the first column and what types cannot when counting? As there are hundreds of these database files in use, injecting a "dummy" column into them just for the sake of counting is not a solution. [edit] I was able to create a dBase 5 table and it exhibited the same behavior. When I added the extra column, however, no exceptions and counting worked fine. [/edit] [edit2] I was able to successfully count records in the table using the ODBC API (e.g.,SQLDriverConnect(),SQLExecDirect(),SQLGetData()) rather thanCDatabaseandCRecordset. [/edit2]"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous