Alpha Software Mobile Development Tools:   Alpha Anywhere    |   Alpha TransForm subscribe to our YouTube Channel  Follow Us on LinkedIn  Follow Us on Twitter  Follow Us on Facebook

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 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
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Ray in Capetown
    replied
    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.
    Last edited by Ray in Capetown; 03-11-2013, 04:29 AM.

    Leave a comment:


  • JetLi
    replied
    Re: Help on Nework Speed

    Originally posted by Ray in Capetown View Post
    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.
    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
    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!

    Leave a comment:


  • Ray in Capetown
    replied
    Re: Help on Nework Speed

    Originally posted by Tom Cone Jr View Post
    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.

    Leave a comment:


  • Ray in Capetown
    replied
    Re: Help on Nework Speed

    Originally posted by JetLi View Post
    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.
    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
    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.
    Last edited by Ray in Capetown; 02-11-2013, 06:26 PM.

    Leave a comment:


  • Tom Cone Jr
    replied
    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:


  • csda1
    replied
    Re: Help on Nework Speed

    Originally posted by JetLi View Post
    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.

    Leave a comment:


  • JetLi
    replied
    Re: Help on Nework Speed

    Originally posted by Ray in Capetown View Post
    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.
    I just do a lookup to the products table, and post the qty sold to the qty on hand. nothing more and nothing less.if there are no records yet on the sales header and sales details, it takes about a sec to scan the barcode and display the item, price and the total. as sales are accumulated, I can notice the change starting from 200 records, if I scan a barcode with that number of sales details, it will now take 2 sec, and of course as sales are again accumulated, it will be noticeable, and by 1500 sales details and about 300 sales header entry, I can notice the change to be 4 sec. Doing sales using a barcode and waiting for 4 sec before scanning another item is too long.But if I am going to use the server as the stand alone POS, the 1500 records will take about 2 sec to display the Item, price and total.

    Leave a comment:


  • Ray in Capetown
    replied
    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:


  • JetLi
    replied
    Re: Help on Nework Speed

    Originally posted by Ray in Capetown View Post
    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.
    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.

    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:


  • mronck
    replied
    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:


  • Ray in Capetown
    replied
    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:


  • JetLi
    replied
    Re: Help on Nework Speed

    Originally posted by mronck View Post
    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.
    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.

    Leave a comment:


  • mronck
    replied
    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:


  • Ray in Capetown
    replied
    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:


  • doorscomputers
    replied
    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:

Working...
X