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

File-Server vs. Client/Server Tutorial

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • File-Server vs. Client/Server Tutorial


    Just for the curious


    http://www.qview.com/support/version4/faq0009.htm



    Cheers

    Marc
    www.a5solutions.com
    Marc King
    A5solutions

  • #2
    RE: File-Server vs. Client/Server Tutorial

    Hey Marc...helpful. Thank you.
    Mike
    Thank you,
    Mike Konoff

    Comment


    • #3
      RE: File-Server vs. Client/Server Tutorial

      At the risk of adding to confusion, I'd like to put the essence of client-server into a form that should be familiar to Alpha Five users.
      Imagine that I have a single-user system, and I have a an invoice report called as follows:

      preview_report("Overdue Invoices","date()-invoice_date>90 .and. balance_due>5")

      This report will print all invoices with balances of 5 dollars or more that are more than 90 days outstanding.

      On a single-user system, this report will look at my invoice table and examine every single invoice in deciding which ones to include in the report. Perhaps only 2% of the invoices are more than 90 days overdue, but all the invoices have to be examined.

      Now I move to a networked setup. The invoice table is maintained on a file server someplace, and I am sitting at my workstation, hitting the same button to prepare the report.

      The same process happens--the report generator has to look at every single record in the table. The entire invoice table is sent by the fileserver over the network to my workstation, and my workstation does the work of examining each record. In essence, my workstation has no idea that the table is not local.

      Now let's move to a client-server environment. I want, again, to run the same report. This time when I press the button to run the report, the report filter is sent to the server, which is now an intelligent server. The server interprets the filter and looks locally at the table and does the record selection for me. It then sends me only the invoices that are 90 days overdue. This is more work for the server but less work for the workstation.

      There are other advantages to most client-server environments besides a reduction in network traffic. The updating of records and indexes is also done by the server, instead of by each individual workstation. When a workstation adds a record, it does so by sending the new record to the server with a request to add it to the table. Another way of looking at it is that the server thinks of itself as a standalone computer, answering requests to file data and retrieve data. If a workstation goes down when it has Alpha Five open it doesn't affect the server in the slightest, since the workstation doesn't have any files open on the server.

      Coming back to A5v6, I have no inside information on how Alpha Software will implement client-server, but Alpha has a long history of simplifying complicated technology. I would imagine that most applications will not need any reworking. Having said that, I am sure that it would be possible to improve the performance of client-server applications by attention to the structure of the application, but the rules are probably going to be the same as those that apply to current multiuser networked applications: keep your sets small, open only the tables you need for the task at hand, pay attention to work flow, etc.

      Feel free to criticize or add to this, since I'm not an expert!
      - Peter Wayne

      Comment


      • #4
        RE: File-Server vs. Client/Server Tutorial

        Hi Peter,

        "The server interprets the filter and looks locally at the table and does the record selection for me. It then sends me only the invoices that are 90 days overdue. This is more work for the server but less work for the workstation."

        That's the key, the query is performed at the server level and only the rows that you need are transferred.

        Peter, one of the hardest things I needed to overcome when I've started client-server programming was that you don't need to deal with the entire record set.

        After all how many row/ records can a human being edit at one time. When you need a table count, you don't need to transfer all the rows to your local workstation and have all that traffic court across the wire. Just ask the server and the only piece of information to you get back it the table count.

        Sincerely,
        RF-ARS-Motorola

        Comment


        • #5
          RE: File-Server vs. Client/Server Tutorial

          Marc,

          I was lucky enough to keep this documentation that I used when I've first started client-server programing. This documentation is pretty much over kill and deals with advanced client-server techniques. I've always kept this as a reference.

          Again this is pretty much over kill and just too much information that the average user doesn't need, but it really goes into details for those who are interested.

          Sincerely,
          RF-ARS-Motorola

          Comment


          • #6
            RE: File-Server vs. Client/Server Tutorial

            Peter,

            Thank you for your example. It helps, or at least it did for me, without getting into a lot of confusion about terminology.

            I usually do not deal with large networks (I mean a huge number of users) or with terribly large tables, so network traffic has not yet become a major concern with most of my applications.

            You wrote: " There are other advantages to most client-server environments besides a reduction in network traffic. The updating of records and indexes is also done by the server, instead of by each individual workstation. When a workstation adds a record, it does so by sending the new record to the server with a request to add it to the table."

            You don't explicitly say it, but my understanding is that since only the server can add or update a record (row, jamdang or whatever!), all my record/table locking problems can at least theoretically be over (if I do everything according some hoyle or another).

            Some users will think, gee, my v5 network apps do not have record locking issues, so why does Ray have so many problems in that regard? One reason (there may be others) is that most of my apps deal mostly with imported data. Users update data but rarely do they enter new data. Plus it is not uncommon for 2 or more users to be using the same record at the same time, or for a user to need to run an update that includes a record that someone else is in the middle of changing. Now, in v5 there are imperfect ways of dealing with some of this. But if under client/server (or flang/danger) the workstations do not directly do anything to a table/record, then if the server does it's job correctly, my understanding is that my record/table locking woes are over.

            That is the main reason I am looking forward to A5v6. It would also be nice if the table structure were such that a field that is sometimes 100 characters long does not require 100 characters worth of bandwidth (bigbangwidth?) when it is empty. But that is nothing compared to record locking issues I run into.

            Ray Lyons

            Comment


            • #7
              RE: File-Server vs. Client/Server Tutorial

              Thereís little question that the world is heading to client-server technology; in fact Bill Gates has stated his intended goal of making MSSQL the desktop standard. I wouldnít bet against him. But not applications are improved by client-server technology. Remember, you lose the advantages of Distributed Processing. If, say, you had an app that had many small tables where a number of users were constantly accessing the data and performing multiple queries; it may prove more efficient to run it against a file server engine thusly taking the load off the server to do all the work. Itís hard for me to imagine such an app, but it should not be dismissed. And while Iím not sure of the speed of MySQL, MSSQL is a dog. Oracle runs rings around it.

              Notwithstanding, MSSQL is slowly becoming the standardÖnot surprising with MS buying the top names in accounting software and dropping all other platforms except MSSQL. And accounting software is by far the dominant factor in software sales in the US and even influences other sales of software.

              Does client-server mean you can ignore record-locking when designing an app. No, it doesnít. Client-server can resolve certain issues, you change a record and release the record; I change the record and release it. The engine can make that change successfully even if neither record had been committed to the DB. But most all other record-locking issues must still be handled in your code as it should be. However, a big advantage of client-server is Transaction Processing: the ability to handle Commit and Rollback. Transaction processing can ďundoĒ prior changes when a change operation fails somewhere within the operation. In reality, it doesnít really undo the change but simply never applies the change from a transaction file. The Codebase Client-Server engine supports Commit and Rollback. And of course, Client-Server makes it much more possible to get your app to a wider user base. Personally, I think A5V6 is going to be an incredible product and I canít for its rollout.

              Comment


              • #8
                RE: File-Server vs. Client/Server Tutorial

                Steve,

                I have absolutely nothing personal against you. The only reason I even responded was because people were little bit confused about Alpha 6.

                People at Alpha will be the first to admit that their terminology could use some refreshing at times is quite confusing; we've had this conversation before years ago on this board.

                As people helped me when I first started, I intend to return the favor. And forgive me if I have mastered and to program in client/server.

                But if terms are not fully understood this will lead to confusion. People don't really care what you call this or that as long as what they are using works. But, I do find when trying to learn something new or try to understand it, got to get the meaning down straight.

                Would it shock you to learn the term front-end and back-end was use by Richard Rabins on this board in describing Alpha 6, and I am very sorry to disappoint you, but the rest of the world has accepted this and now Alpha is trying to incorporate this into their product to increase its value to its consumers.

                It's hard for me to just sit back when you make comments like these:

                "And while Iím not sure of the speed of MySQL, MSSQL is a dog. Oracle runs rings around it." - third party tests, having nothing to do with Microsoft shows MSSQL slightly faster, but then again Oracle will come out with their test show Oracle slightly faster - the difference is always an nanoseconds - unless your Mr. Data from Star Track - who cares.

                "Does client-server mean you can ignore record-locking when designing an app. No, it doesnít. Client-server can resolve certain issues, you change a record and release the record; I change the record and release it." - there is no release of record in a Client Server System and depending on your cursor types there is no record locking.

                I can't wait for the release of version 6, I'm extremely curious how certain issues are going to be resolved. I still support a few of my friends still using Alpha products.

                I hope I have not done anything personally to upset you this was never my intention, but anything I say I can and will be able to back it up with overwhelming proof.

                Respectfully;
                RF-ARS-Motorola

                Comment

                Working...
                X