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

  • #16
    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.
    Regards,

    Ira J. Perlow
    Computer Systems Design


    CSDA A5 Products
    New - Free CSDA DiagInfo - v1.39, 30 Apr 2013
    CSDA Barcode Functions

    CSDA Code Utility
    CSDA Screen Capture


    Comment


    • #17
      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.

      Comment


      • #18
        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.

        Comment


        • #19
          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.

          Comment


          • #20
            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!

            Comment


            • #21
              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.

              Comment

              Working...
              X