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!

Register Log in
  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

.dbf files mysteriously gone missing (or being deleted)

Vince Wen

Vince Wen

Programmer
Jun 15, 2024
22
HK
I have a VFP9 program where users can install on either their local workstation (C:) or put on a network server for multiple users to use.
There have been several instances (perhaps 3-4 instances this year) where .dbf files have mysteriously gone missing. It is a different .dbf file each time, and there does not seem to be a pattern.
As far as I can tell, the cases have all been happening when the software is on the network server. I have a case where the user was using the program just fine and suddenly it errors with: "File [xxx].dbf file does not exist". This doesn't make sense to me as the user had to be accessing the .dbf file to run the program, and I certainly don't have any code that would delete the .dbf file.
So far, this has only been happening to files on network servers. It has not happened to our C: installations. Of course, this could just be a coincidence.
Does anyone have any hypothesis for me? Or any advice as to where I should begin my investigation?
- Vince
 
Sort by date Sort by votes
Chriss Miller said:
That's basically not the problem in a company environment, where users have limited permissions. Using computer management needs admin permissions.

You still have a point. The simple solution to avoid deleting files is not giving that permission to users, which obviously still depends on them being non admin users. In a comapny that's very usual, though.

If you're concerned about the safety of your data the short answer is not to use DBFs but a MSSQL or MySQL or PostgreSQL backend or whatever else.
Click to expand...
Computer management is an easy way to do it.

If you really want to see that physical access equals root access they can sniff the ethernet :D then you are screwed. SMB is clear as day.

or even an IP scan can still get you the name of the remote server. Hell even in my network places ( if that is still named as it was in the past you can still find them out )

Regarding your solution to ditch DBFs you are right. Its the only sensible way. BUT the software would need an ALMOST complete re-write and I am sure the DEV is long gone.
 
Upvote 0 Downvote
A_Radiolog_inFoxPro said:
Computer management is an easy way to do it.
Click to expand...
I don't know how good you are at user management, but you can clearly limit company users to not use system components, disable them to install any software or run any software uninstalled, too. The core thing to use is group policies restricting what users can do. I worked for a company only allowing excution of whitelisted executables. So they couldn't simply run something, not even a portable browser or other such software. Not even VFP on a stick. Anyway, all of that only applies to a company network.
 
Upvote 0 Downvote
Chriss Miller said:
I don't know how good you are at user management, but you can clearly limit company users to not use system components, disable them to install any software or run any software uninstalled, too. The core thing to use is group policies restricting what users can do. I worked for a company only allowing excution of whitelisted executables. So they couldn't simply run something, not even a portable browser or other such software. Not even VFP on a stick. Anyway, all of that only applies to a company network.
Click to expand...
Believe me when I say. Physical access = Root access.

I saw many PCs that were locked down being opened like a book by some skilled people.
- Remove Boot password ( reset the bios , several work arounds )
- Boot of a USB with windows / PC unlocker etc etc
- Create local admin user
- All your management policies go out the window. ( removed the monitoring too .... ) and the story goes on.
If someone wants to do you harm will find the way. The only way is not to give them a reason to do so.

And never forget most attacks and Brute forcing comes from inside the network not from outside. ( from people with access )

Thanks
 
Upvote 0 Downvote
There's Sir Veillance hindering that. And working contracts. Legal stuff.

In short: There's no perfect safety, but there also isn't a perfect crime.

I'm very sure the outcome will either be the DBF is found in quarantine or Vince finds code that deletes the file, unintentionally, of course.

I'm not out of an idea why a user would sabotage a software. Reasons could be manifold. Wanting to stick to currently used software, making way for another software from competition. There's always possible reasons for sabotage, sure. But it won't be my first idea, ever. And if that would be the core reasaon, I think the staff responsible for choosing the software would have suspects.
 
Last edited:
Upvote 0 Downvote
Vince Wen said:
I have a VFP9 program where users can install on either their local workstation (C:) or put on a network server for multiple users to use.
There have been several instances (perhaps 3-4 instances this year) where .dbf files have mysteriously gone missing. It is a different .dbf file each time, and there does not seem to be a pattern.
As far as I can tell, the cases have all been happening when the software is on the network server. I have a case where the user was using the program just fine and suddenly it errors with: "File [xxx].dbf file does not exist". This doesn't make sense to me as the user had to be accessing the .dbf file to run the program, and I certainly don't have any code that would delete the .dbf file.
So far, this has only been happening to files on network servers. It has not happened to our C: installations. Of course, this could just be a coincidence.
Does anyone have any hypothesis for me? Or any advice as to where I should begin my investigation?
- Vince
Click to expand...
Hi Vince, I have seen this happen when the connection between client PC and server gets interrupted while VFP is updating tables. If you look in the folder containing the data files you will probably find a file with a strange name created recently - this is the temporary file used by VFP when manipulating a database. If you rename that file back to the missing dbf all will probably be OK. The root cause is a momentarily interrupted connection between the PC & server and some of the causes I have seen are: Using Wifi of the clients PC (never reliable with VFP), Faulty network cable, Faulty network wiring, faulty network switches. Hope this helps.
 
Upvote 0 Downvote
Hi Vince,
It's a far shot, but I'd recommend to take a look at FileSystemWatcher (FSW) in the Visual Studio Help.
I made a program in the past (albeit in VB .NET, VS 2022) based on this "control", and it did work. By that latter I mean it reported when a file of a monitored type disappeared from the monitored directory.
I do not have the code at hands anymore, but there are several threads about in the VB .NET section on this forum, you might want to look them up, there are some codes in there.
HTH.
 
Upvote 0 Downvote
Chriss Miller said:
Surely possible. I guess EinTerraners questions are trying to understand, if users actually see a mapped drive and know where files can be found and then be manipulated. The question then is what's in for a user that wants to use the software to delete a dbf?
Click to expand...
Chriss, EinTerraner, A_Radiolog,
I am temporarily ruling out malicious actor or even user error.
I absolutely acknowledge that our users will know the data folder path and *can delete them.
I simply don't think this is the case here. Our users are typically small business owner with a few staff. Also, the scenarios don't fit:
- In one case, the owner is the only one using our software. There isn't any good reason to sabotage himself.
- In one case, the user that reported the error (missing a critical .dbf file) was in the middle of using our software. The software *requires the missing .dbf file to even run. Which means that .dbf file was there when he first started the program, and half way through, it couldn't find the .dbf file anymore. Sure, anything could be possible, but I don't think it fits the scenario.
 
Upvote 0 Downvote
EinTerraner said:
One Question. Does this missing tables have memo-fields (.fpt) and/or indexes (.cdx) an are those also missing?
Click to expand...
They do NOT have memo-fields. They have indexes.

In one of the cases, I am certain the .cdx file is still there, only the .dbf file went missing. (This one happened yesterday, so fresh in my mind)
I'm struggling to remember the other cases. I am tempted to say the .cdx remained and only the .dbf files were deleted.
 
Upvote 0 Downvote
Talbess said:
Hi Vince, I have seen this happen when the connection between client PC and server gets interrupted while VFP is updating tables. If you look in the folder containing the data files you will probably find a file with a strange name created recently - this is the temporary file used by VFP when manipulating a database. If you rename that file back to the missing dbf all will probably be OK. The root cause is a momentarily interrupted connection between the PC & server and some of the causes I have seen are: Using Wifi of the clients PC (never reliable with VFP), Faulty network cable, Faulty network wiring, faulty network switches. Hope this helps.
Click to expand...
Thank you. I did not realize this. I admit I did not think of looking for a file with a strange name. Does the 'strange name' have any pattern? Ie. do they have a consistent file extension I can try to look for?
 
Upvote 0 Downvote
IlyaRabyy said:
Hi Vince,
It's a far shot, but I'd recommend to take a look at FileSystemWatcher (FSW) in the Visual Studio Help.
I made a program in the past (albeit in VB .NET, VS 2022) based on this "control", and it did work. By that latter I mean it reported when a file of a monitored type disappeared from the monitored directory.
I do not have the code at hands anymore, but there are several threads about in the VB .NET section on this forum, you might want to look them up, there are some codes in there.
HTH.
Click to expand...
Thank you. I haven't used FSW before, but I will look into it.
 
Upvote 0 Downvote
As far as I understand, the file disappearing event doesn't occur when the program only run on local disk. Only when connected to the network.

Vince Wen said:
Our users are typically small business owner with a few staff.
Click to expand...
Does they have a machine running exclusive as a server (7/24) or just a dedicated pc-workstation with the shared folder?

 
Upvote 0 Downvote
EinTerraner said:
So You do not use UNC-Paths

Does your missing tables have memo-fields and/or indexes (xxx.FPT / xxx.CDX). Are they missing too or only the "xxx,DBF"
Click to expand...
Hi EnTerraner,
(I think I replied to this already. I don't find this forum software easy to follow... so I will reply again)
- We do use UNC-Paths in some cases. But not in the cases I am referring to. In all those cases (with missing .dbf) they are using a mapped letter drive.
- The missing tables do NOT have .fpt. In one case, the .cdx file definitely was there and only the .dbf file was missing. I am struggling to remember the other cases.
 
Upvote 0 Downvote
EinTerraner said:
As far as I understand, the file disappearing event doesn't occur when the program only run on local disk. Only when connected to the network.


Does they have a machine running exclusive as a server (7/24) or just a dedicated pc-workstation with the shared folder?
Click to expand...
That's correct (at least so far). So far, this is only occurring when the data is on a network server.

I believe in all cases they use exclusive server (24/7) and not a workstation with shared folder. I cannot say for certain, since I cannot keep up with all our users' infrastructure setup. But in all cases, they were able to call on their tech support and 'restore' to an earlier point, which seems to be more typical of a dedicated server.
 
Upvote 0 Downvote
Vince Wen said:
In one case, the .cdx file definitely was there and only the .dbf file was missing.
Click to expand...
I got this already.

I had once a similar problem, but more then 15 yrs ago before i upgraded to VFP9 (used VFP6). Also only on network-drives. And running on W2k/XP-machines. Sadly about same time i upgraded all my progs to VFP9. So I didn't really follow this behavior.

Are You familiar with https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shchangenotify ?
 
Upvote 0 Downvote
Chriss Miller said:
The only VFP commands that actually delete a DBF and create a new one are PACK and ALTER TABLE, PACK creates a new DBF file, moves all undeleted records into it
Click to expand...
Hi Chriss,
Thanks. I didn't know this and this is important to know.
- In one of the cases, this *might explain it. The user distinctly said he marked some records for deletion, and then he went to a different section of our program to permanently remove it, which I think triggers PACK in our program.
- However, in the other cases, I don't think this explains it.

That said, it is certainly possible that the cases have different causes. It is possible that in the first case it was caused by an incomplete PACK and the other cases caused by something else entirely...
 
Upvote 0 Downvote
Vince Wen said:
The user distinctly said he marked some records for deletion, which I think triggers PACK to permanently remove those records
Click to expand...
😁I just was writing the PACK-Stuff like Chris mentioned before.
I stopped use the PACK on a network-drive, because this process can take a lot of time. Instead of PACK I do BLANK this record and re-use it when I insert new data. (datarecycling).
 
Upvote 0 Downvote
Talbess said:
I have seen this happen when the connection between client PC and server gets interrupted while VFP is updating tables.
Click to expand...
Neither SQL (Insert/Update/Delete) nor xBase (Replace, Append, Delete) do that. I wonder what you mean by updating tables.

I already mentioned ALTER TABLE, if you mean structural updates, but they are not the normal operation. And by the way, not even using transactions creates new/other files, just like manual record locks. They work with locks in the file system. That doesn't lead to missing dbf files.

Vince,
Vince Wen said:
Does the 'strange name' have any pattern? Ie. do they have a consistent file extension I can try to look for?
Click to expand...
Simply´same name, other extensions. The only documented file extensions for backups are .bak (dbf) and .tbk (fpt) when using MODIFY STRUCTURE (or using the table designer, manually). AFAIK VFP creates such TEMP files in the same directory as the original files, not in TEMP. So you'd find them in the data directory.
 
Last edited:
Upvote 0 Downvote
@Chriss Miller
A bit of a naive question/solution - is it reasonable to automatically scan for .bak files without equivalent (same name) .dbf files, then automatically rename the .bak to .dbf?

I understand this doesn't solve the root cause of the issue, but I'm just wondering if there are potential downside to this line of thinking
 
Upvote 0 Downvote
You must log in or register to reply here.

Similar threads

ajenat
  • Question
Can NOUPDATE prevent a DBF corruption
Replies
11
Views
486
tomk3
tomk3
Premal Vala
  • Locked
  • Question
VFP with MYSQL - mySQL server gone away
Replies
8
Views
947
Chris Miller
Chris Miller
german12
  • Locked
  • Question
Transferring the names of text files to a *.dbf file 1
Replies
5
Views
417
german12
german12
gbcpastor
  • Locked
  • Question
Export Foxpro 9 DBF to Dbase 5 File 1
2
Replies
22
Views
2K
Don Child
Don Child
Allwolfpackfan
  • Locked
  • Question
Convert Foxpro Memory Variable to a DBF
Replies
9
Views
513
Chris Miller
Chris Miller

Part and Inventory Search

Sponsor

Back
Top