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 IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Huge Delay Accessing .DBF files

Status
Not open for further replies.

MikeJanko

Programmer
Jan 23, 2003
2
US
Hello, I have developed many multi-user Quicksilver .EXE compiled applications which run flawlessly in DOS. Using VM/386 I have had no concurrency issues and my applications were as close to real-time as the language allowed. I was quite proud of my work, until recently, when I had to install some applications on W98, W-Me, and W-XP networked computers.

At first, everything worked perfect, but as of late, I have run into the following problem. The site which has NT server and a completely separate site which is just peer to peer have the same issue. ONCE in a WHILE, the program just "hangs," while fetching from OR writing to the hard disk. If you are patient and wait (up to 60 seconds), eventually the data gets read or written and everything "catches up." In the real world, the application users don't wait and exit through system mgr which, of course, causes index file errors and faulty records.

It appears to me to be some type of network issue, but I am the one under pressure to make this thing work! Any system settings, registry entries, tips and ideas are GREATLY appreciated. THANK YOU for any help you can provide.

Mike Janko
 
I must forwarn you that I have no "Quicksilver" experience, so all I can offer is just an idea; until someone else offers a fix.

since you wrote the code and I presume that you still have the original code, add a display to the console saying:
"Please wait..Server Busy..estimated link time: 1 minute"

You may also want to start backing up the data (just incase), or maybe create a seperate "OldData.dbf" and copy/move data that is not accessed any longer to it that may help (even if only just a little).

That's all I can offer without Quicksilver knowledge.
--MiggyD

PS: you may want to list these "install some applications" as well.
 
Thanks MiggyD....Most of my users are impatient, plus they are so used to other programs that "hang" they don't even think twice about "X"ing out! I really feel this is some sort of network issue. Some cache setting somewhere that is waiting for a certain amount of bytes to be requested to be read or written before actually doing it. Many of the records being read and written are very small. Thanks for tryin'
 
Yeah, it kind of sounds like that to me as well. I remember our 2k servers were flying until we installed AV and added inet connection then BOOMMM!! <sounds of computers hitting walls>.

ended up tweaking the AV for a day and a half. Now everthing is back to the incrediable yester-year speeds of <what feels like a 386-66DX @ 2X> 133 MHZ (instead of the normal 400+) LOL.

Anyway, you may want to try it out. Some--and I mean 1/8th of the users I have to deal with--will actually READ a message <if you can believe it> and wait.

Of course the others end up calling me. So, back to work I go.

Good Luck,
MiggyD
 
Mike...

I agree with you that it's got something to do with the network connections. I, too, have developed many applications with Quicksilver but have never experienced the problems you're having.

Some things to think about...
1. Where are the datafiles stored? On the NT machine or on a W98 machine? You might want to put them all on one or the other - preferably with application files.
2. Maybe someone is attempting to print a report - which takes a huge amount of time from the DOS window - that it's effectively stalling the application.
3. I've had to do this once or twice - set up the system so that updates are &quot;batch processed&quot; at certain intervals. This leaves the main tables untouched by users (client-server type) and protects the index files.

I still think it's in the network somewhere but without some serious tracing software, it's going to be tough to prove. If you ever do find the answer, let us know.

And good luck!

There's always a better way...
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top