VFP6 Database problem

[chronos446]

Good day to you all,

I need help on troubleshooting some database problems on our company payroll system that is based on VFP6.

Current setup is we have one desktop(win10) that serves as the "server", VFP6 and the payroll app is installed there along with the entire payroll database. VFP6 is then installed to the client pc and connects to the server via a payroll app shortcut leading to the server. The payroll app is directly accessed through the server's network drive and the data is being encoded to it by multiple users.

My only issue then is that we're already hitting the 20 concurrent connection limit on this win10 desktop, and I'm already in the process of setting up a real server with either a windows server 2008 or a linux based server(looking at ubuntu server, centos or debian w/samba4). Transfer the payroll system to this new server and finally setup a domain.

Now for a couple of months the system was working fine, a couple of hiccups here and there due to our mixed network environment and problems from our aging hardware. But all of sudden last week the payroll system went bonkers, I found out that a couple of days of encoded data was not saved in the database. My encoders could see the encoded data a couple of weeks back but any encoded data made and saved wont register in the database. There were also a couple of errors like "Record is out of range" and database not updated. Now to be honest I'm a completely new to VFP and I really don't know how to troubleshoot this errors. So if you guys have any tips on how to I would gladly appreciate it. Thanks

 

[Mike Lewis]

Welcome to the forum.

As I was reading your post, I found myself wondering why you had VFP installed on the "server" and on the client PC that is "connected to the server". Are you aware that you would normally run your application from a compiled EXE file, and that you do not need VFP itself to be installed? VFP is the development environment. It is possible that you are running your application directly in the development environment, but that is not at all a normal thing to do.

The normal approach is to have an executable program, and to install that, along with certain VFP runtime files, on every client workstation. That way, you are not constantly hitting the server with requests for bits of the executable. That alone might reduce or eliminate some of the problems you are seeing.

Setting up a dedicated Windows 2008 server would clearly be an improvement on using a Windows 10 machine as a server. I'm not sure about Ubuntu, though. I have no experience of trying to run VFP apps under Ubuntu, and don't know if it is possible, but in any case I can't see any advantage over a proper Windows server (except price, perhaps).

Regarding your "record out of range" and similar errors, these are normally caused by errors in the program code, and might be quite separate from the other problems you have been seeing. The normal approach to dealing with program errors is to run the code in the VFP debugger, and to examine variables, etc. at the point at which the error occurs.

But you say you have no experience of VFP programming. So the next question is: Who developed your VFP application? And is that person still available? If not, you might need to find a VFP programmer who can help you, but that person would definitely need access to the application's source code. Do you have the source code, or can you lay your hands on it?

I'm sorry I can't give you a simple fix that will solve these problems. Other people here might be able to provide more insights.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[TamarGranor]

I think the first place I'd look for all of this is the possibility of corrupted indexes. If the application provides a way to regenerate the indexes, try that. Note that you'll have to get everyone out of the application in order to do that.

Tamar

 

[GriffMG]

Unless the part on the server is actually processing something - preparing reports or something - that requires VFP then there is no reason your data could not be on a Linux server running SMB or similar - that makes it a basic NAS (which could be a good option).

I would suspect your corruption is being caused by Op's Locks though, look into removing them before you go too far down other routes.



Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[dbMark]

I agree with Tamar. Once the initial problem occurred, the index may be corrupted and can't be trusted until the indexes are REINDEXed. It's possible one or more users were updating the table and/or index (which meant adding records and data to the table and index files) and before it could complete that process other user(s) tried reading/writing and got the error because the index didn't match the table. So it could be a file or record LOCK issue. Or maybe the OS blocked access. Maybe having SET REPROCESS (if in VFP6) set to retry a few times might help? And if a browse window is being used then you might want to determine what SET REFRESH is.