I created a simple VB program that insert records to
DBase III file by Insert SQL statements. The program ran fine and created a new records, but after that I cannot open that file on DBase by USE or BROWSE command. It throws a message that my file is not a database file.
I use this type of connection
If this is the first time your dBase III plus programme has failed to recognise a dBase file, you are very lucky. I have given up trying to find the cause. What I do is to rename the existing unrecognised file (do it in the windows command prompt) say "TEST.DBF" (The extension is important")
I then create a new dBase III file using the original name and set up the fields exactly as before. (If this happens regularly with the same file you could hold a duplicate structure somewhere)
Open the newly created (but empty) file and execute the dBaseIII Plus command
append from TEST.DBF
If you hold a back up file from before the corruption, you could simply copy the structure from that.
In the case of badly corrupted dBase files which will not respond to the above, I have found that importing the corrupted file into Access and then carrying out the above procedure from the Access file work perfectly.
Thank taxes for your reply. I gave up and push it to another guys. They tried to use Sybase package to do it, but I did not see if they've done it finally.
I have a question - is it any other driver, except Microsoft that could be used to run INSERT SQL statements for DBaseIII+?
"I have a question - is it any other driver, except Microsoft that could be used to run INSERT SQL statements for DBaseIII+?"
Not that I ever came across, but then, I stuck entirely with dBaseIII Plus right up to 2002 - I gave up with visual dBase after all the bugs in dBase iv)
Remember that SQL had no involvement with dBaseIII Plus, at least I have never seen it in any dBaseIII Plus literature. The dbase equivalent was VUE files. I don't know why you say "except Microsoft ".
I thought your problem was that you could not make a dBaseIII Plus table from VB or Access. It sounds like you should be exporting your dBase tables to Access if you do not have the facility to run dBase III Plus as a programming language.
EDIT: Having thought about it, you MUST have the full dbaseIII Plus package. You can't get the database section as a stand alone. If you don't understand how to use the .VUE facility and it becomes necessary, let me know.
What is happening is that behind the scenes, VB/Jet handles dBase files like foxpro. As a result, when the data within the file is changed, the timestamp in the dBase file header gets changed in a manner that is Y2K compliant, but cannot be properly handled by dBase, so you are subsequently unable to open the file in dBase...
Was able to fix the issue by doing a binary repair to the file after data operations. The timestamp in the dbase file header is in offset position #2 in the file, so the trick is to replace the data there with the current year.
Create the following sub in your app
Sub FixDBF(FileName As String)
' This fixes the DBase header date.
' This is done because of Dbase not being able to read the 2001 date
Dim iFile As Integer
Dim sRet As String
Dim X As Integer
iFile = FreeFile
Open FileName For Binary As #iFile
For X = 1 To 2
'NEEDED - Initialize the return value size.
sRet = Space(1)
Get #iFile, X, sRet
If X = 2 Then
sRet = Chr$(Val(Right$(Date$, 2)))
Put #iFile, X, sRet
Now in your data routine(s), after the data has been edited, etc and the table is closed, you call
You should now be able to open the file in dBase as normal.