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 derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
DBF Damaged
- Thread starter jotita
- Start date
Jotita,
I don't really have enough to go on to help with your issue. The size of your DBF is not really relevant here... When you say, "Always have registers with 2 char displayed to the right", what are you refering to? What is a "Register". If all data in a field has 2 leading space characters, it's most likely some piece of code that is placeing them there. The fact that your database is multiuser is irrelivant as well.
Please provide more information, and I'm sure one of us here will try to assist you.
Thanks,
-Scott
Please let me know if this has helped! s-)
I don't really have enough to go on to help with your issue. The size of your DBF is not really relevant here... When you say, "Always have registers with 2 char displayed to the right", what are you refering to? What is a "Register". If all data in a field has 2 leading space characters, it's most likely some piece of code that is placeing them there. The fact that your database is multiuser is irrelivant as well.
Please provide more information, and I'm sure one of us here will try to assist you.
Thanks,
-Scott
Please let me know if this has helped! s-)
HI,
I have an unteresting case similar to this...
1. You have a multi user setup... so obviously, some one is using an excell or some such other program to open the DBF file. When they open with specific.. file ext. name.. example.. myTable.DBF ... it opens the file and then stores them back with those 2 character shifting (Their way of storing the file). When next time you open the Table from FoxPro.. it shows NOT A DBF FILE error.
2. Also, a similar opening of the file locks up the table and so the other users in the multiuser setup get either frozen.. locked or whatever... (since the external software opens the DBF as EXCLUSIVE)
The above took some time by the client to identify and they kept sulking till the cat was out of the bag.
Hope this experience helps the forum members for quicker diagnosis.
ramani :-9
(Subramanian.G)
FoxAcc
ramani_g@yahoo.com
LET KNOW IF THIS HELPED. ENOUGH EXPERTS ARE HERE TO HELP YOU OUT! BEST OF LUCK
I have an unteresting case similar to this...
1. You have a multi user setup... so obviously, some one is using an excell or some such other program to open the DBF file. When they open with specific.. file ext. name.. example.. myTable.DBF ... it opens the file and then stores them back with those 2 character shifting (Their way of storing the file). When next time you open the Table from FoxPro.. it shows NOT A DBF FILE error.
2. Also, a similar opening of the file locks up the table and so the other users in the multiuser setup get either frozen.. locked or whatever... (since the external software opens the DBF as EXCLUSIVE)
The above took some time by the client to identify and they kept sulking till the cat was out of the bag.
Hope this experience helps the forum members for quicker diagnosis.
ramani :-9(Subramanian.G)
FoxAcc
ramani_g@yahoo.com
LET KNOW IF THIS HELPED. ENOUGH EXPERTS ARE HERE TO HELP YOU OUT! BEST OF LUCK
- Thread starter
- #4
- Thread starter
- #5
Jotita,
Well, one solution to "Fix" your existing data is to simply issue a replace all on the field, for example:
REPLACE ALL CITH WITH ALLTRIM(CITY)
This will remove the unwanted spaces from the front and back. If it is sporadic in your table, the most likely cause is, as Ramani suggested, an import field. Long term, there are a few ways to deal with this.
Part of the speed of Fox in import situations is the ability to bring in fixed length data, or named fields from an excel spreadsheet, without haveing to specify each field. What I would do in this case, instead of importing them directly into your main table, is first import them into a staging table, where you do data clensing first. That staging DBF would have the same structure as your final DBF. Bring in the records, always process a few things against it like the replace all I listed above to remove unwanted spaces, and then just append it to the final table with:
SELECT <Production.DBF>
APPEND FROM <Staging.DBF>
Where "Production.DBF" is the final location for the data, and "Staging.DBF" is the interim table. Make sure you "Empty" the staging table each time before bringing in a new batch of data to clense.
Thanks,
-Scott
Please let me know if this has helped! s-)
Well, one solution to "Fix" your existing data is to simply issue a replace all on the field, for example:
REPLACE ALL CITH WITH ALLTRIM(CITY)
This will remove the unwanted spaces from the front and back. If it is sporadic in your table, the most likely cause is, as Ramani suggested, an import field. Long term, there are a few ways to deal with this.
Part of the speed of Fox in import situations is the ability to bring in fixed length data, or named fields from an excel spreadsheet, without haveing to specify each field. What I would do in this case, instead of importing them directly into your main table, is first import them into a staging table, where you do data clensing first. That staging DBF would have the same structure as your final DBF. Bring in the records, always process a few things against it like the replace all I listed above to remove unwanted spaces, and then just append it to the final table with:
SELECT <Production.DBF>
APPEND FROM <Staging.DBF>
Where "Production.DBF" is the final location for the data, and "Staging.DBF" is the interim table. Make sure you "Empty" the staging table each time before bringing in a new batch of data to clense.
Thanks,
-Scott
Please let me know if this has helped! s-)
- Thread starter
- #7
While everyone else seems to be concentrating on fixing your data problem, you might want to find why it's being corrupted in the first place. I've seen these kind of "data shifts" due to:
1) Bad Disk controller on server
2) Bad area on Disk on server
3) Bad Memory being used in server file cache
4) Bad NICs, hubs, routers, switches, cabling
5) Bad Memory in workstation
6) Bad Disk controller on workstation
7) Bad area on Disk on workstation
Because it's likely that any of these conditions is intermittent (otherwise you be having mass failures), you'll need to perform some controlled diagnostic testing on your whole network.
Rick
1) Bad Disk controller on server
2) Bad area on Disk on server
3) Bad Memory being used in server file cache
4) Bad NICs, hubs, routers, switches, cabling
5) Bad Memory in workstation
6) Bad Disk controller on workstation
7) Bad area on Disk on workstation
Because it's likely that any of these conditions is intermittent (otherwise you be having mass failures), you'll need to perform some controlled diagnostic testing on your whole network.
Rick
- Thread starter
- #9
Well, if it's an every day problem, you might try disconnecting a few of the work stations every day until you find a day there isn't a problem or you run out of PCs. Indeed, you might be able to do it even easier if some stations are down every day by people being off work.
Or you might check and see if you have the problem on weekends when there might be fewer or no computers connected. If you have a spare hub, you might be able to switch them one at a time and see what happens.
Your server might be more difficult, though if you have the problem on weekends when nobody's hooked up, it might be an indication.
Dave Dardinger
Or you might check and see if you have the problem on weekends when there might be fewer or no computers connected. If you have a spare hub, you might be able to switch them one at a time and see what happens.
Your server might be more difficult, though if you have the problem on weekends when nobody's hooked up, it might be an indication.
Dave Dardinger
- Status
Similar threads
- Locked
- Question
