Help on Nework Speed

[csda1]

Re: Help on Nework Speed

Yes, I did test it and it is fast when I was beginning to add records, it is getting slower when more records are added.If this is the case, then I will delete sales data everyday so that it will be fast everyday.

Assuming you are using a LAN and not a WAN (You can not use a WAN without the correct remote software) then if it is getting slower with records, then it means that you either have bad indexes in a table in the set (very unlikely, but a rebuild of indexes eliminates this) or you are not using the correct code. It sounds like you are doing queries that are not using LQO, and not doing Finds (which basically just immediately find a value in an index. This is very typical of someone using action scripting, and either choosing the wrong action script action to perform, or doing it in a very bad method. Many action script lines can be very inefficient, and the only way to make them work fast is to convert them to XBasic and fix the generated code.

I've had 100 users constantly entering and searching data in an Alpha Four system with only a 10 megabit network a long time ago, with absolutely no problem. Even the most poorly created queries should be able to handle 10000 records for most uses, but for instant access all queries should be invoking LQO, or better yet, use Finds in the the index. Doing this, then it should not matter how many users you are using, and how many records are in the tables.

Many XBasic functions (such as TABLECOUNT) invoke queries in their operations. If they are not doing LQO (generally because the inputs are not in a form that recognizes an index for LQO or you don't have an index with the correct expression), it will/can be slow.

Finally, a faster CPU/system will not make any difference for bad code. Built-in network cards are not a reason for slowdowns (unless broken). OS software is also not to blame unless an anti-virus program or some type of disk caching system (which could be in the OS) is operating on the data folder.

[Tom Cone Jr]

Re: Help on Nework Speed

To add to Ira's good advice let me mention one other thing I've seen lately. More and more folks are using realtime backup systems (like Carbonite, for example). These can impair performance and in some cases even lead to data corruption. Better to go old school and do your backups when the system is not being used for data entry.

[Ray in Capetown]

Re: Help on Nework Speed

Ray, How do I purge to history? What do you mean by "run pos offline from the server when remote, and connect to update both ways"?
Hope you can share a sample app on how you implement it.

As requested Jet - if it helps - I lifted a section of working code from a similar application of mine to try illustrate, simplified and commented for you to look at.

'-4- 	COPY TO ARCHIVE INVOICE HEADER		--------------

vphArch = table.open("invh_archive",FILE_RW_SHARED) 'my archive header table
vphArch.enter_record(r2vh)  'Add the header record (I previously copied)
vphArch.close()

'-5- 	COPY LINES TO ARCHIVE , and CALC LEDGER POSTINGS

vplArch = table.open("invl_archive",FILE_RW_SHARED) 'my archive lines table
CurinvL=table.current(2)	'0,1= "invhshadow" 2= "invlshadow" 3= "stmas"
curinvl.fetch_first()
while .not. curinvl.fetch_eof()
	CurinvL.record_to_vars(r2vl) 'copy the invoice line
	r2vl.invnum = newinvno 'the newly allocated invoice number
	r2vl.invseq = newinvseq 'the newly allocated linking sequence number (to later reprint the invoice if required for copy)
	vplArch.enter_record(r2vl)	'Add record to the Invoice ARCHIVE Lines
	curinvl.fetch_next()
end while

this is part of a procedure that runs after each invoice is completed, then the print follows. this leaves an archive record of every invoice,
The current invoice can be cleared for the next. Its reasonably instantaneous because it just appends.

[Ray in Capetown]

Re: Help on Nework Speed

To add to Ira's good advice let me mention one other thing I've seen lately. More and more folks are using realtime backup systems (like Carbonite, for example). These can impair performance and in some cases even lead to data corruption. Better to go old school and do your backups when the system is not being used for data entry.

At last some good sense Tom.
I read people proudly announce they can make backups whilst tables are open.
They are open because PEOPLE ARE BUSY POSTING - in any integrated system its pretty likely you get unbalanced part entries and half updated values. How disastrous would that recover be.

[JetLi]

Re: Help on Nework Speed

As requested Jet - if it helps - I lifted a section of working code from a similar application of mine to try illustrate, simplified and commented for you to look at.

'-4- 	COPY TO ARCHIVE INVOICE HEADER		--------------

vphArch = table.open("invh_archive",FILE_RW_SHARED) 'my archive header table
vphArch.enter_record(r2vh)  'Add the header record (I previously copied)
vphArch.close()

'-5- 	COPY LINES TO ARCHIVE , and CALC LEDGER POSTINGS

vplArch = table.open("invl_archive",FILE_RW_SHARED) 'my archive lines table
CurinvL=table.current(2)	'0,1= "invhshadow" 2= "invlshadow" 3= "stmas"
curinvl.fetch_first()
while .not. curinvl.fetch_eof()
	CurinvL.record_to_vars(r2vl) 'copy the invoice line
	r2vl.invnum = newinvno 'the newly allocated invoice number
	r2vl.invseq = newinvseq 'the newly allocated linking sequence number (to later reprint the invoice if required for copy)
	vplArch.enter_record(r2vl)	'Add record to the Invoice ARCHIVE Lines
	curinvl.fetch_next()
end while

this is part of a procedure that runs after each invoice is completed, then the print follows. this leaves an archive record of every invoice,
The current invoice can be cleared for the next. Its reasonably instantaneous because it just appends.

Hi Ray, I cannot figure out what is r2vl and invhshadow, invlshadow and stmas. May I request again a working app of this so that I can see how you implement this, I can see that your approach is indeed faster and I want to implement this in my app. Hope you can share a variation of your app modified so that we can see how it is implemented. Thanks!

[Ray in Capetown]

Re: Help on Nework Speed

r2vh and r2vl are pointer variables dimmed as
dim r2vh as p - could be any other var name
inv*shadow are shadow tables we have discussed before. I wouldn't recommend your using those without a clear overall design plan and care. They make you data view extremely mobile within your application.
I use record_to_vars(), a function explained and directed to you in other posts. It has to be understood to be used successfully.
I have shared with you often, my working code, leads to more questions, you want me now to share my application.. that would likely then elicit coaching.
As Tom has mentioned to you recently - start with pseudo code, you can see as well as show how all the elements hang together.
Then as you work out code it is in context of a flow and you can get help with points where you get stuck.