Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
NOT A DATABASE FILE 1
- Thread starter martinr
- Start date
Go Get This Program<br><A HREF=" TARGET="_new"> <p>David W. Grewe<br><a href=mailto
ave@internationalbid.net>Dave@internationalbid.net</a><br><a href= > </a><br>
ave@internationalbid.net>Dave@internationalbid.net</a><br><a href= > </a><br>You might give this a try first:<br><br><A HREF=" TARGET="_new"> <p>Robert Bradley<br><a href=mailto: > </a><br><a href= - Visual FoxPro Development</a><br>
- Thread starter
- #4
- Thread starter
- #6
To MZABARY:
Networks can cause various problems such as loss data packets, corrupted memory, flaky client. I've had a lot experience with Foxpro DOS and Novell. Give me a detailed inventory (description) of your server for starters.
Bill
Networks can cause various problems such as loss data packets, corrupted memory, flaky client. I've had a lot experience with Foxpro DOS and Novell. Give me a detailed inventory (description) of your server for starters.
Bill
advancepack
Programmer
For small Database & faster machines i would suggest for rewriting data. try to write data by low level function FCREATE, FWRITE these files never damage due to power failure.
Hi Bill/All
I am realy not sure what kind of info needed to get me help.
I have Novell 4.11 server running perfect for 5 or more years. All 45 stations connected with windows 98 novell 32 client, some with MS client for novell. I have 2 stations connected to the server with dos (6.22) client. the functionn of those station is to record trafic to part of the building with barcode membership scaned. One operate great with no errors the other as I said 2-3 times a day get this error "NOT A DATABASE FILE". I change the computer three times, I recabled the station. I worked with no INDEX,
I copy the records to another file and copy back to server with foxpro copy all command. WHAT ELSE CAN BE DONE?
I am realy not sure what kind of info needed to get me help.
I have Novell 4.11 server running perfect for 5 or more years. All 45 stations connected with windows 98 novell 32 client, some with MS client for novell. I have 2 stations connected to the server with dos (6.22) client. the functionn of those station is to record trafic to part of the building with barcode membership scaned. One operate great with no errors the other as I said 2-3 times a day get this error "NOT A DATABASE FILE". I change the computer three times, I recabled the station. I worked with no INDEX,
I copy the records to another file and copy back to server with foxpro copy all command. WHAT ELSE CAN BE DONE?
-
1
- #12
Make sure you are running current Novell clients on all the workstations, and make sure they AREN'T running the default configurations. A number of Cache settings need to be altered - I won't name the specific ones, because Novell in it's infinite wisdom has changed their descriptions and the number available in different clients. There are a number of articles on the Novell support site discussing these settings. Search on Foxpro, cache, etc.
Rick
Rick
Guest_imported
New member
- Jan 1, 1970
- 0
- 0
- 0
To Mzabary:
If understand you, you have 2 PCs, configured identically, using the same DOS client both of them. They are doing the same tasks - therefore, they are accessing the same data files. One works fine, one gets the error message 2-3 times a day. You've replaced the PC (the whole thing) more than once but no fix. You've re-cabled the workstation. Correct so far?
More questions (some are obvious...) regarding the bad PC:
1.) Did there used to be a PC at this station that was working correctly? If so, what has changed - I mean ANYTHING?
2.) Explain what you did when your re-cabled the workstation - what part of the network did you re-cable?
3.) Have you swapped the two PCs between locations to see if the problem moves or not?
4.) Do you have access to any packet monitoring (or sniffing) equiptment to determine packet loss, noise, etc.?
Let's start by getting answers to these questions.
Bill
If understand you, you have 2 PCs, configured identically, using the same DOS client both of them. They are doing the same tasks - therefore, they are accessing the same data files. One works fine, one gets the error message 2-3 times a day. You've replaced the PC (the whole thing) more than once but no fix. You've re-cabled the workstation. Correct so far?
More questions (some are obvious...) regarding the bad PC:
1.) Did there used to be a PC at this station that was working correctly? If so, what has changed - I mean ANYTHING?
2.) Explain what you did when your re-cabled the workstation - what part of the network did you re-cable?
3.) Have you swapped the two PCs between locations to see if the problem moves or not?
4.) Do you have access to any packet monitoring (or sniffing) equiptment to determine packet loss, noise, etc.?
Let's start by getting answers to these questions.
Bill
Guest_imported
New member
- Jan 1, 1970
- 0
- 0
- 0
To Mzabary:
If understand you, you have 2 PCs, configured identically, using the same DOS client both of them. They are doing the same tasks - therefore, they are accessing the same data files. One works fine, one gets the error message 2-3 times a day. You've replaced the PC (the whole thing) more than once but no fix. You've re-cabled the workstation. Correct so far?
More questions (some are obvious...) regarding the bad PC:
1.) Did there used to be a PC at this station that was working correctly? If so, what has changed - I mean ANYTHING?
2.) Explain what you did when your re-cabled the workstation - what part of the network did you re-cable?
3.) Have you swapped the two PCs between locations to see if the problem moves or not?
4.) Do you have access to any packet monitoring (or sniffing) equiptment to determine packet loss, noise, etc.?
Let's start by getting answers to these questions.
Bill
If understand you, you have 2 PCs, configured identically, using the same DOS client both of them. They are doing the same tasks - therefore, they are accessing the same data files. One works fine, one gets the error message 2-3 times a day. You've replaced the PC (the whole thing) more than once but no fix. You've re-cabled the workstation. Correct so far?
More questions (some are obvious...) regarding the bad PC:
1.) Did there used to be a PC at this station that was working correctly? If so, what has changed - I mean ANYTHING?
2.) Explain what you did when your re-cabled the workstation - what part of the network did you re-cable?
3.) Have you swapped the two PCs between locations to see if the problem moves or not?
4.) Do you have access to any packet monitoring (or sniffing) equiptment to determine packet loss, noise, etc.?
Let's start by getting answers to these questions.
Bill
To: Bill / All
The 2 stations login with the dos client. 2 of them sharing few database, however the database the get currepted is used ONLY by that station that cause the curreption. I may add that it is happened while I am tring to append record.
I used RLOCK(), LOCK() and FLOCK() all same error. I tried few PC's that working ok. I recable the station with new wire and jack to the hub. I Do not have access to any packet monitoring (or sniffing) equiptment to determine packet loss, noise, etc.
Thanks.
The 2 stations login with the dos client. 2 of them sharing few database, however the database the get currepted is used ONLY by that station that cause the curreption. I may add that it is happened while I am tring to append record.
I used RLOCK(), LOCK() and FLOCK() all same error. I tried few PC's that working ok. I recable the station with new wire and jack to the hub. I Do not have access to any packet monitoring (or sniffing) equiptment to determine packet loss, noise, etc.
Thanks.
deanwarner
MIS
I have not worked out how to use this site properly yet but I hope martinr reads this.
I have had problems and the following seems to have fixed them all.
Novell 4.11 - load on SP9 if you haven't already.
Upgrade client on pc's to 3.32.0.0.
In the advanced settings do;
Turn off "cache writes"
File Cache level set to 0
use extended file handles = on
close behind ticks = 0
opportunistic locking = off
NB the symptoms you are having was one of the ones I got.
Regards
Dean
I have had problems and the following seems to have fixed them all.
Novell 4.11 - load on SP9 if you haven't already.
Upgrade client on pc's to 3.32.0.0.
In the advanced settings do;
Turn off "cache writes"
File Cache level set to 0
use extended file handles = on
close behind ticks = 0
opportunistic locking = off
NB the symptoms you are having was one of the ones I got.
Regards
Dean
MelindaPeirce
Programmer
I have exactly the same problem with a novell 4.11 server, and two workstations running Win-NT. they use the same application on two different "databases". One never has a problem corrupting files, the other does it every other day. Don't know if we have SP9 for novell, but there is an upgrade planned to go to Novell 5.1 in the near future. Does anyone know of any issues with Foxpro and Netware 5.1?
Second question, is there some setting I should look for on the pc that keeps corrupting files? I have requested that that pc be scratched and rebuild from the OS up, but if there is an easier way, I'd sure like to know about it.
Thanks
Melinda
Second question, is there some setting I should look for on the pc that keeps corrupting files? I have requested that that pc be scratched and rebuild from the OS up, but if there is an easier way, I'd sure like to know about it.
Thanks
Melinda
Melinda,
We support sites using both 4.11 and 5.1, and as Dean suggests, the BIG problem is that the default settings for the Netware clients is "wrong" for FoxPro databases (actually any applications that write a lot of shared data!). While different clients may have different property names (and some may be missing), you just have to make sure any that resemble those he listed are set properly. If you look hard enough on the Novell support site, you'll find articles that say essentially the same thing.
You have to be almost obsessive about making sure that ALL the workstations that access your data are set right - just one wrong one can cause trouble for everyone! Be vigilant - everytime a new system is added or the client (or server) is updated, these settings need to be checked / set properly. (I've seen updates reset to values back to the "wrong" defaults. <s>)
Rick
We support sites using both 4.11 and 5.1, and as Dean suggests, the BIG problem is that the default settings for the Netware clients is "wrong" for FoxPro databases (actually any applications that write a lot of shared data!). While different clients may have different property names (and some may be missing), you just have to make sure any that resemble those he listed are set properly. If you look hard enough on the Novell support site, you'll find articles that say essentially the same thing.
You have to be almost obsessive about making sure that ALL the workstations that access your data are set right - just one wrong one can cause trouble for everyone! Be vigilant - everytime a new system is added or the client (or server) is updated, these settings need to be checked / set properly. (I've seen updates reset to values back to the "wrong" defaults. <s>)
Rick
Guest_imported
New member
- Jan 1, 1970
- 0
- 0
- 0
Error 'Not a Database File' appears mostly at the time of adding records to the file. With every added record the size of the file increases, but the directory entry of the file is updated only when the file is closed.
When a system switches off or hangs in the process of adding records, directory entry does not get updated.
Foxpro stores the number of records, last update date, etc. in the firts few bytes of the DBF file. With every USE, it checks the size of the file based on number of records and record size and discards the file when this does not match with the directory entry.
The best solution to this is to append a few bytes to the end of the file using COPY (in DOS mode) and check. When the size of the file matches or exceeds the size calculated by Foxpro, the error will go.
When the file opens successfully, last few records will have to be created again and all related IDX files will have to be REINDEXed.
This check was not done in dBASE III PLUS or FoxPlus. The corrupt 'Not a Database File' opens in FoxPlus successfully but shows blanks against last few records which go beyond the size of file as per directory.
USE the file in FoxPlus. Create a DBF with a different name using COPY TO <filename> and this new DBF will open in Foxpro without fail.
When a system switches off or hangs in the process of adding records, directory entry does not get updated.
Foxpro stores the number of records, last update date, etc. in the firts few bytes of the DBF file. With every USE, it checks the size of the file based on number of records and record size and discards the file when this does not match with the directory entry.
The best solution to this is to append a few bytes to the end of the file using COPY (in DOS mode) and check. When the size of the file matches or exceeds the size calculated by Foxpro, the error will go.
When the file opens successfully, last few records will have to be created again and all related IDX files will have to be REINDEXed.
This check was not done in dBASE III PLUS or FoxPlus. The corrupt 'Not a Database File' opens in FoxPlus successfully but shows blanks against last few records which go beyond the size of file as per directory.
USE the file in FoxPlus. Create a DBF with a different name using COPY TO <filename> and this new DBF will open in Foxpro without fail.
- Status
Similar threads
