VOUCHER FORM NETWORK ERROR

[Bondjames]

network at 2 places at the same time one node goes through and the second lan node has to wait for few seconds till the transaction in the first one is not completed
the records are heavy i agree but i noticed that it will due to the coding in the program can anyone advice what changes to be made in the coding in the method there is dbfupdt method which is the where the changes have to be made (according to me).

please advice as to what changes should be made and oblige
regards

 

[Chris Miller]

It seems to me you want to kow how to do transactional process without transactions. If there are reasons, and there are, only one transaction can be processed at a time, then the next one has to wait for the first one to finish. The best thing you can do is make all your code faster so transactions don't need to wait long for each other, but you can't remove the need to process transacations in a queue one after the other.

Chriss

 

[Bondjames]

yes Sir Mr. Chriss i want make my code faster like adding scan endscan and so on but i am not that expert so if you could guide me to some extent would be really helpful.
yes the second will be entered in the dbf once earlier is finished but the problem is when there are many records i have to wait for many seconds and just it shows signs of buffereing and i have to wait till the other node completes and i enter at times the program escapes out also
regards

 

[Chris Miller]

The dbfupdt is 277 lines of code in which no bottleneck is obvious. What is obvious is that the code does not use a transaction at all, nor any manual locking.
Without you first narrowing down which part of the dbfupdt code takes long, there's no way to help you.


Chriss

 

[tomk3]

Hello,

I remember a prolemwith DBF in a network : fast on first PC,slow on next one using it.
I think it was something about SMB , oplocks, not sure..

Maybe someone remembers better, we completely switched to MS-SQL+VFP (and others) several years ago, so I have no details in our KB.

Best regards
tom

Found that :

https://www.tek-tips.com/viewthread.cfm?qid=1792835

 

[Gerrit Broekhuis]

For what it’s worth: we switched to MySQL 20 years ago and got rid of all the slowness and performance issues.

Regards, Gerrit

 

[Chris Miller]

There are a few pointers you could follow up.

1. You say in your subject title there is a network error. What error number and message is it? Just telling there is a network error is not telling what the problem is, does it?

2. I said you have to find out the bottleneck to optimize and accelerate existing code, so what you can do first is measure how long the different sections of code take.

One simple method is defining a log routine that helps you see where most of the "few seconds" are spent to address that part. SECONDS() will tell you the time up to milliseconds, there are more precise methods, but I doubt you need them, STRTOFILE() is the easiest function to write a file or add a line to it aka log text, but you can also log into a dbf, just store records. And yes, this logging will of course add to the time, but you can limit that by writing to local drives, don'T log into the network drive, at start of the EXE you could copy the last session log to a central network share, empty the log file or just erase it and start over. That way you can still collect log informations over a longer period and find out which parts of dbfupdt take long, whether this only happens on specific workstations or any other pattern.

If you find out the whole time spreads evenly across all the 277 lines, then there's not much you can do, the whole time obviously depends on what saving changes actually means.

A few seconds is long when the whole change is about storing a single changed field of a single record in a single DBF. But I see the code does a lot of appending, so maybe the few seconds are quite normal for what you do in the dbfupdt method.

One thing that is typical for any system is that it starts out working fast with a small set of data, and performance degrades when the dbf files become larger. So one thought should always be is there data you can remove, at least move it into an archived section of data. AS a typical example of a shop with an order system. The essentially important orders are the ones not yet processed fully. Once an order is fulfilled data about it becomes uninteresting for order fulfillment, it only is interesting for management, statistics about prodcuct inventory or marketing research about product popularity and surely for tax, etc, but you don't need to keep every record in a main system, keeping your DBFs small accelerates a system.

Chriss

 

[Bondjames]

Thank you Chris Miller,Tomk3,Gerrit

 

[Chris Miller]

Well, it doesn't sound like you got it going, also in your other thread184-1829497, but didn't want to leave a lingering open end of these threads. Don't worry, the forum will close a thread after a long time of no further participation anyway, you can always get back to it, or better yet refer back to it in a new thread by the thread number, like I did here refer to your DLL thread with the threadxxx-yyyyyyy number that is shown right unde the thread title.

So, once you have a more specific question about the two topics, of course you can start a new thread and refer that it is a detail continuation of your older threads that way.

Chriss