0

I'm currently trying to debug an issue with a legacy system at my company. The original project was developed in the mid 90's, and everyone who knew the system has left the company. Currently we're seeing an error with one of the .DBF files, a simple table that holds no more than 4-5 columns, and barely any rows. The message the system is sending us is that we cannot open Message.dbf in Shared Mode.

Is there a way to open the database in an exclusive mode? We have a system with DBFManager and a Visual FoxPro 6.0 set up. Any hints, or links to information on these types of databases would be helpful. We have nobody with knowledge of these systems. I wish I could provide more detailed information, but I'm at a loss here.

So far we've tried replacing the file with several backups we had on the system, and restarting the server the .DBF file was located in (In case of a lock issue). So far nothing has solved the issue.

Corey
  • 398
  • 1
  • 4
  • 18

3 Answers3

2

You mention you have VFP 6... I would start with opening up VFP. In the command window, type 

CD "C:\wherever Your Application Data is"    (enter)
use Message SHARED   (enter)
browse normal    (enter)

If you can see the content of the data, then there is no corruption going on with the file.

This obviously is a recent problem for such an old application. When you mention opening the file in "Shared" mode. Was there code added to open the file? If so, was the "Message" table already opened and in use by the same alias? If so, that would cause it to fail. You can't open the same table with the same "alias" name in two different work areas. If this is the case, you might be able to try and resolve by doing something like...

if used( "Message" )
   select Message
else
   select 0
   use Message
endif 

... continue with rest of code...

PER COMMENT / FEEDBACK

If it was from a server shut down, I HAVE seen that before where the file appears to be locked by a user from an invalid disconnect.  Sometimes, it just required all users to just logout / login again to force a release of all their resources to the server... but if the actual SERVER was shut down and restarted, then the users sessions would have been cleared anyhow.  I would check to see WHO the server still THINKS has the Message.dbf table still opened.  Additionally, if need be, kick all users out and manually use the table in VFP EXCLUSIVELY, and just for grins, PACK it

I would also do a backup via simple copy/paste of the entire folder where the data is located... THEN start VFP and do the following...

cd "whatever path"
use Message EXCLUSIVE
PACK
use

If it was part of a database, the database might be corrupted somehow / somewhere. To test that...

cd "whatever path"
close all
open database YourDatabase Exclusive
Validate Database

and see what it gives you

...

One more comment. I see you mention NetWare (Novell). Something I have seen in the past... Have there been any users recently deleted from the system (ie: from NetWare)? If so, and a file was originally created by "that user", then once that user is gone, so too are all permissions to do anything with that file. What you are best to do is login as administrator, select all the files and "Take Ownership" of them as administrator. The admin will never have restrictions to add/edit and can never be deleted as a user, thus never have this problem again. Again, just another option I remembered from history and MIGHT be part of the issue.

DRapp
  • 47,638
  • 12
  • 72
  • 142
  • I'll start trying the command line. I'm able to open the table in VFP. This is an application running that's attempting to use the Message.dbf file, I do not readily know where the original code is, or if we even have access to it. The issue started after a power outage where several of the servers needed to be quickly shut down. – Corey Apr 11 '12 at 19:02
  • Was able to browse the table with VFP. We've restarted the server the application accessing the Message.dbf file was on several times, and also restarted the server where Message.dbf is physically stored. (The servers communicate using Netware). Would it be possible for a user accessing the Message.dbf file to lock the system out? (Two applications being referred to here, one is the server to handle requests, another is a client where users can edit records on their computers) – Corey Apr 11 '12 at 19:13
  • @Corey, see revision per your comment. – DRapp Apr 11 '12 at 19:15
  • Thanks for the very detailed reply. I've tested the PACK commands you gave me, to no avail. I'm going to try and find the name of this database (There is basically no documentation for this D:). Our Netware admin is currently on vacation, so when he's back in a few days I'll talk to him about checking through the files. Thanks for all the help so far. – Corey Apr 11 '12 at 19:27
  • Finally got into the original code. The problem is coming from a line IF (!USED("Filenamehere")) ...Continued code. Do you know if USED is a native FoxPro 6.0 command? – Corey Apr 16 '12 at 20:16
  • Yes, USED() is a VFP function, and it's been available since well before VFP 6. It checks whether a particular alias is in use in the current data session. That is, it asks "is some table open using the specified alias?" – Tamar E. Granor Apr 16 '12 at 21:03
  • @Corey, correct per Tamar's comment to me (which I obviously knew), but USED() is a valid function, but as noted, is expecting an ALIAS name and not a value that would include an extension, such as "Message.dbf". by including the ".dbf" portion will make it fail. – DRapp Apr 16 '12 at 21:17
1

I haven't come across NetWare for many years, but back in the day I used to have continual fights with it because Client32 For Windows, when using default settings, did not play nicely with the FoxPro / Clipper DBF locking mechanism. This, for example.

Alan B
  • 4,086
  • 24
  • 33
  • I passed your advice along to our Netware administrator. He went through the advised steps and we're still running into the same issue. Not sure if it's a locking issue since we can still open the .DBF file in FoxPro, and view contents etc. It seems as this legacy system is the only one having issues accessing it. – Corey Apr 16 '12 at 20:17
  • If it's any consolation, we have one customer using an old FoxPro 2.6 system (i.e. pre Visual FoxPro even) on a recent Netware setup, with maybe 50 users. So it *is* possible. – Alan B Apr 17 '12 at 08:03
  • Sounds awful to keep up with. We've been banging our head against the wall for the past week trying to figure out what this system needs. If you know if the "USED" function does for FoxPro, I'd be gracious. The only person in the company who knew this system passed away recently, leaving a very large gap in knowledge :( – Corey Apr 17 '12 at 18:23
  • 1
    The USED() function returns true if a specified alias is in use in any work area - for example USED("mytable") will return true if a table or cursor called mytable is open in any work area. I would suggest maybe subscribing to the ProFox mailing list at http://leafe.com/mailman/listinfo/profox A lot of long-time FoxPro people are on that list, even if they aren't involved with Fox any more. I know a fair few of them have experience with DBFs on Samba and various other things. – Alan B Apr 18 '12 at 08:18
0

We weren't able to debug exactly what the issue with opening the .dbf file was. In stead, we found a backup of the system that was several weeks old, and were able to restore the entire system to that state. The program is currently working fine, though we were unable to find the cause of the issue originally.

Corey
  • 398
  • 1
  • 4
  • 18