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.
Announcement
Collapse
The Alpha Software Forum Participation Guidelines
The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
Moderators may also rename posts and threads if they are too generic or do not property reflect the content.
Moderators may move threads if they have been posted in the incorrect forum.
Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.
The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.
Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.
Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.
Bonus TIPS for Successful Posting
Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.
When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.
The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.
When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.
A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.
If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.
When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.
Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
- Be professional in your conduct
- Be kind to others
- Be constructive when giving feedback
- Be open to new ideas and suggestions
- Stay on topic
Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
- Spam.
- Vulgar language.
- Quotes from private conversations without permission, including pricing and other sales related discussions.
- Personal attacks, insults, or subtle put-downs.
- Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
- Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
- Sexually explicit or violent material, links, or language.
- Pirated, hacked, or copyright-infringing material.
- Encouraging of others to engage in the above behaviors.
If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
- Remove the Post or Thread - the content is removed from the forum.
- Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
- Temporarily Ban the User - user is banned from forum for a period of time.
- Permanently Ban the User - user is permanently banned from the forum.
Moderators may also rename posts and threads if they are too generic or do not property reflect the content.
Moderators may move threads if they have been posted in the incorrect forum.
Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.
The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.
Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.
Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.
Bonus TIPS for Successful Posting
Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.
When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.
The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.
When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.
A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.
If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.
When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.
Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less
Help on Nework Speed
Collapse
X
-
Re: Help on Nework Speed
Originally posted by Ray in Capetown View PostAs 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.
Code:'-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
The current invoice can be cleared for the next. Its reasonably instantaneous because it just appends.
Leave a comment:
-
Re: Help on Nework Speed
Originally posted by Tom Cone Jr View PostTo 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.
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.
Leave a comment:
-
Re: Help on Nework Speed
Originally posted by JetLi View PostRay, 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.
Code:'-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
The current invoice can be cleared for the next. Its reasonably instantaneous because it just appends.Last edited by Ray in Capetown; 02-11-2013, 06:26 PM.
Leave a comment:
-
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.
Leave a comment:
-
Re: Help on Nework Speed
Originally posted by JetLi View PostYes, 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.
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.
Leave a comment:
-
Re: Help on Nework Speed
Originally posted by Ray in Capetown View PostJet
you are skirting the issue. WHY are sales slowing down with only 1500 transaction records?
They need not be parsed during invoicing, just appended to - read this sentence again.
Can you explain what else you do with these transactions during invoicing.
Leave a comment:
-
Re: Help on Nework Speed
Jet
you are skirting the issue. WHY are sales slowing down with only 1500 transaction records?
They need not be parsed during invoicing, just appended to - read this sentence again.
Can you explain what else you do with these transactions during invoicing.
Leave a comment:
-
Re: Help on Nework Speed
Originally posted by Ray in Capetown View PostWhat I would be looking into Jet, is why more sales records are slowing it down significantly.
Sales records in POS would traditionally simply append. Speed would not be affected noticeably.
Generally an "end of day/shift" procedure SHOULD do some updates and purge to history anyway.
No performance hit should affect invoicing. I often 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.
Found a solution for my problem, I deleted all the 1,500 sales details and 700 sales header and the app was fast again. I will try to talk to the user if they are going to allow me to put a button to delete their sales everyday so that their sales transactions will be faster.Last edited by JetLi; 02-10-2013, 09:04 AM.
Leave a comment:
-
Re: Help on Nework Speed
1- How did you test the network, with what type of equipment and what were the measurements on speed you concluded on? How "slow" exactly does it become when records are added?
2- Assuming the network hardware is correct and your observation about speed dropping when records get added is correct as well: check the design of your indexes. What indexes do you have, how many on which tables. Check if they are really necessary and if they are well chosen design-wise. This looks like an index related matter. But:
3- Before you do so exclude corruption due to all kinds of development activities: run a compact database from the CP.
Leave a comment:
-
Re: Help on Nework Speed
What I would be looking into Jet, is why more sales records are slowing it down significantly.
Sales records in POS would traditionally simply append. Speed would not be affected noticeably.
Generally an "end of day/shift" procedure SHOULD do some updates and purge to history anyway.
No performance hit should affect invoicing. I often run pos offline from the server when remote, and connect to update both ways.
Leave a comment:
-
Re: Help on Nework Speed
Originally posted by mronck View PostTo begin with, "slow response" is a very subjective description. What exactly is "slow" or "fast" in they eyes of the OP?
Secondly, I remember OP posting a thread in exactly the same subject not too long ago, where several tips were given.
As more often the question is only a few lines of text, but one could write books on the answer.
Jetli, did you hard test the speed of the network without even a database being in the equation? With other words: is/was the network OK before you even started with A5?
The best way to solve any problems with networking is to start at the very beginning and go from there step-by-step eliminating the most obvious possible culprit first and then go to the second and so forth.
Leave a comment:
-
Re: Help on Nework Speed
To begin with, "slow response" is a very subjective description. What exactly is "slow" or "fast" in they eyes of the OP?
Secondly, I remember OP posting a thread in exactly the same subject not too long ago, where several tips were given.
As more often the question is only a few lines of text, but one could write books on the answer.
Jetli, did you hard test the speed of the network without even a database being in the equation? With other words: is/was the network OK before you even started with A5?
The best way to solve any problems with networking is to start at the very beginning and go from there step-by-step eliminating the most obvious possible culprit first and then go to the second and so forth.
Leave a comment:
-
Re: Help on Nework Speed
Best practise for POS is
1. that each terminal WRITES sales info only, to their own, READ ONLY table/s. This is useful for cashing up, changing shift etc as well but mostly the speed. With 50 (i haven't done) but I would have them write these files "dropped" (ie not added) and even on the local drive
2. item list tables formally indexed and READ ONLY
3. With your 2 PC slow as you say, interrogate your code and explore with different methods (share that portion here). I dont think that sounds right as described. There need be no delay on lookup, print and append only sales detail lines.
Leave a comment:
-
Re: Help on Nework Speed
I guess, I am a bit frustrated because I could not get it to be faster on 2 computers with only 1 accessing the server. Hope I can at least make it fast with 1 user or 2.I'll wait for the purchase of 2 Computers with Corei7 Processor and 32 GB memory with 2 TB hard disk.I'll see if I can make it a bit faster. Thanks for the help Tom.
Leave a comment:
Leave a comment: