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

A5 Desktop-Web-Applications: possibly a new model

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

    A5 Desktop-Web-Applications: possibly a new model

    Consider this article a theory on how Alpha Five version 8, with it's Enterprise Passive Linked SQL capability might be used to power a web community application where tens or even hundreds of thousands of users, participate with little or no server, or bandwidth, constraints. Can Alpha Five do this? I think so. Tell me if I'm wrong.

    You may have noticed that the pricing for multi-user Alpha Five runtime licenses get more expensive the more users you add. Whether you buy a 10 user runtime or a 200 user runtime, the maximum number of users, refers to the maximum number of concurrent users, NOT the maximum number of installed users. This restriction is, I believe, an extension of the the system's record locking logic.

    But what about Passive Link Tables and remote SQL updates? Since no record locking involved, I believe that there are no limits on how many users can access a remote database. Is this true?

    For instance: mySQL database connectivity is included with almost every web hosting plan. And bandwidth use from your web host, doesn't differentiate between HTML bandwidth and mySQL bandwidth, which means using any ordinary web hosting plan, it's possible to have many thousands of users sharing data without incurring any massive hosting or bandwidth costs.

    So here's my idea for a new kind of web-application. Since it uses the A5 desktop runtime, I call them desktop-web-application. It's really a desktop application that uses a remote database exclusively. When A5 refreshes a passive link table, it has the ability to restrict or filter the data, which means, if a time stamp field was added to every record, and that field was an index, then the desktop-web-application would be able to easily read only new data from the server, when refreshing Passive-Link Tables. That's a LOT faster than refreshing the whole table each time! As long as the time stamp is updated each time a user modifies a record, only new data need be read, to keep a full and perfect mirror of the remote database on the local computer.

    Alpha Five makes this easy. Searching and reading data is all done with the Passive Link Tables. The only hitch is that inserting new records, or updating existing records, cannot be done directly to the remote database. At least not in the traditional, networked data base fashion, where with record locking. No. In this way, the logic of a desktop-web-application is much more like a regular web application than a traditional networked database application.

    When inserts and updates are necessary, you have A5 put up a form. Then when the user is ready to write, (just like in a regular web application), they press submit button and a little bit of Xbasic + SQL, updates to the remote database done in an instant. In fact, if you look at the A5 Data Exploer: a right click on any table, gives you you a selection, "SQL Syntax - Insert Statement", where the exact SQL needed is already stubbed out for you. Mapping the Insert or Update form, to the Xbasic SQL statement is easy because both the SQL statement and the A5 form, were created from the same file definition. The SQL insert statement is generated directly from the remote database. The A5 insert or update form is generated directly from the passive link table, which is identical to the remote database.

    Maybe I've got something wrong here. But it seems that using this scenario, these A5 desktop-web-applications are the ideal platform for quickly developing web applications that can potentially handle a unlimited number of users, without high costs or slowing down under heavy usage, even in today's real world environment.

    I must be wrong about something. There has to be a reason why this is not possible. It seem to me that the Alpha Five Enterprise version now makes it easy to create a large scale web applications. Such a desktop-web-application, working off any remote (mySQL) server, with time stamped passive linked records, can potentially do everything a high end Java or PHP web application can do, BUT... faster and more efficiently. I say faster, because there is no server side services, (other than DB access) to slow the CPU. Meaning, the data does not need to be wrapped in HTML AND the DB table data is never read twice, as is always the case when web application users revisit pages for a 2nd or third time.

    So that's my theory? Think about it. Let me know what you think.
    Last edited by neil_albala; 03-29-2007, 02:10 PM.

    #2
    Re: A5 Desktop-Web-Applications: possibly a new model

    I think you are right about the A5 web application server. I recently started using it and I have to say that it is pretty fast and reliable. if you couple Xbasic for database manipulation and Javascript for data validation, you can have a very fast and responsive web application. I currently host 2 web applications on a DSL connection and I got to tell you, they rival other web applications done with PHP and hosted on special servers with t-1 lines.
    If you buy the enterprise version, you can manipulate any database without using a passive link table. so far .dbf tables are an excellent choice for middle size web applications, up to 500 concurrent users ( I think).

    Good job alpha!!
    The Mexican

    Comment


      #3
      Re: A5 Desktop-Web-Applications: possibly a new model

      Let's forget about SQL for a moment.
      Let's say, you have a DB for Hotel reservations and you developed WAS to allow the public to access your data online.

      If user A runs a query on the table on the server to find rooms available on 4/1/07 at the Miami location. The query shows 10 rooms available of which the user likes Rm #1501 because of the Ocean view.

      unbeknownst to User A, user B ran the same query for the same time period and for his luck, user B also likes Rm 1501.

      User A went on to make a reservation for Rm 1501.
      A nano second later, User B went on to make reservation for the same room.

      1-In a one-user app, what will happen with user B?
      2-What will happen if both user A & user B are both able to open the same reservation form, and while user A opened it first, yet he is a slow typist and User B beats him to the punch because she is a faster typist and she entered her info and saved before user A has a chance to?
      Last edited by G Gabriel; 03-29-2007, 06:21 PM.

      Comment


        #4
        Re: A5 Desktop-Web-Applications: possibly a new model

        Along the lines of what Gabriel is hinting at, this is really nothing more than the same type of synchronization problem you have with a central system and several laptop users. To a degree, synchronization works. Would I place my companies data in its trust? Not a chance. Real time processing is just that. It cannot be mimicked with a sync system. And I truly think that the amount of data moving across the net would also be slower than you think.

        Comment


          #5
          Re: A5 Desktop-Web-Applications: possibly a new model

          I see one issue that might arise and which can be easily fixed. If you are going to rely on time stamps, then you MUST make sure the time of the local workstation has the correct time. You would need to read the regional settings of the computer to make sure that users on the east coast aren't overwritten by users on the west coast and so one. You would also need to connect to a time server and verify the time is correct.

          One issue that is not so easily fixed is the user rights limitations withing Microsoft Windows. If a user only has standard user rights, the user or any application the user runs CANNOT change the PC's clock.

          Time issues are things I am used to dealing with since I have written Time and Attendance applications that utilize biometric, swipe and data entry of timecard information. Luckily this was an inhouse project and I have control of user rights.

          Barry Kucher
          ---------------------------------------------------
          Barry Kucher
          http://www.411tech.org

          Comment


            #6
            Re: A5 Desktop-Web-Applications: possibly a new model

            Originally posted by G Gabriel View Post
            Let's forget about SQL for a moment.
            Let's say, you have a DB for Hotel reservations and you developed WAS to allow the public to access your data online.

            If user A runs a query on the table on the server to find rooms available on 4/1/07 at the Miami location. The query shows 10 rooms available of which the user likes Rm #1501 because of the Ocean view.

            unbeknownst to User A, user B ran the same query for the same time period and for his luck, user B also likes Rm 1501.

            User A went on to make a reservation for Rm 1501.
            A nano second later, User B went on to make reservation for the same room.

            1-In a one-user app, what will happen with user B?
            2-What will happen if both user A & user B are both able to open the same reservation form, and while user A opened it first, yet he is a slow typist and User B beats him to the punch because she is a faster typist and she entered her info and saved before user A has a chance to?
            I have seen many websites use a system of locking a record for a predetermined amount of time when someone is reqesting it. To see it in action, go to ticketmaster.com and try to purchase tickets for a show. After the query returns tickets that you have requested you have about 10 minutes before they are released back to the pool.

            Barry Kucher
            ---------------------------------------------------
            Barry Kucher
            http://www.411tech.org

            Comment


              #7
              Re: A5 Desktop-Web-Applications: possibly a new model

              Gab said, "Let's say, you have a DB for Hotel reservations..."

              Agreed. This model would not work for a hotel reservations system. In fact I'd say, this desktop-web-application model, would be a poor choice for any application that required any kind of transaction processing, or time sensitive data, such as scheduling. It's also a bad choice for any kind of retail application, because users are not going to want to download a 40 meg A5 runtime, just to make a purchase. (I think the runtime is about 40 megs)

              There your best choice would be the WAS (the A5 web application server). And let us remember, as Mario pointed out, that the A5 web application server already reads and WRITES to all databases without any coding.

              The desktop-web-application model, that I'm going to be using to develop my applications, will ALL be community based. Here's a few examples of what desktop-web-applications might be good for:

              1- Any kind of classified or ad oriented database. There's lots of new possibilities there, especially when you allow users to post URL's and embeded video references.

              2- A typical forum system, much like the vBulletin system this forum is using.

              3- Any kind of profile based community. Maybe we could share code on how to upload and manage jpg's.

              4- Any kind of internal mail, much like the internal mail you see on youTube, mySpace or even this forum.

              That was a good point from Barry411, about the time stamping. I hadn't thought that through, but now that you mention it... yes time zones would be a problem. I would probably look to poll the server for a time stamp. Or in a worst case scenario, use one of those little activeX controls to grab time from one of the many internet time servers.

              Doug had an interesting idea: that advanced synchronization logic is probably available somewhere as open source, and that logic, could be applied to table synchronization routines, which would allow for much more robust applications. Maybe some of us could work on that together.

              I am VERY encouraged that no one said this can't be done. The profit-model would be identical to most Java and PHP web applications. 1- New users get FREE access. 2- Income comes from premium services or advertisements.
              Last edited by neil_albala; 03-30-2007, 01:29 PM.

              Comment


                #8
                Re: A5 Desktop-Web-Applications: possibly a new model

                Neil:
                It certainly can be done. That's the magic of the internet, so long as you are aware of the limitations.

                And one other point:
                with it's Enterprise Passive Linked SQL capability might be used to power a web community application where tens or even hundreds of thousands of users, participate with little or no server, or bandwidth, constraints
                Remember, the bottleneck here will be...alpha itself.

                ..and yet another point, the main point:
                with little or no server.
                there will always be a server..data do not exist in vacuum. Those passive links SQL, connect to data on a server that exists somewhere...so you are substituting your own server with those server(s) indirectly through alpha!
                Why?
                Only advantage(s) would be:
                a-Bigger Server
                b-Better server
                c-No need to maintain the server.

                Otherwise, I don't see any other benefits.

                You are just using alpha to connect to and piggy-back on the "big boys".
                Last edited by G Gabriel; 03-30-2007, 03:16 PM.

                Comment


                  #9
                  Re: A5 Desktop-Web-Applications: possibly a new model

                  ..Cut short of finishing the last reply:

                  ...don't take me wrong: this is a great idea to "Leverage" alpha and tab into the big server(s), as if, they were your own.

                  Comment

                  Working...
                  X