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

New Run Engine Question

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

  • Re: New Run Engine Question

    Originally posted by Richard Rabins View Post
    Dave on another thread i posted a reply to this reply from you


    Quote:
    Originally Posted by DaveM View Post
    Richard,



    Per seat means a computer( you would only license the computer) user means the app can be on 200 computers but only the limit osf users can access at one time. I have a 20 nuser runtime and if I don't restrict it, only 20 users can run my app at any given time.



    Dave - thanks for explaining your requirement - this is helpful.

    We will look into how this might be achieved
    Thanks

    This simple distinction between what the runtimes have historically been to what is now being presented is what is the most troubling to me. Perhaps Alpha can look into offering a "floating license" that works the same as the original runtimes. My companies Oracle based ERP system works like this. Our CAD system works like this. We can install on as many PCs as we want, the limit is on the number of active connections. We have that now with the V8 runtime.

    Offering both options with a higher price on the floating license model would allow the developer to price their apps according to the customer's needs. If my customer needs the option of floating licenses as opposed to fixed seat licenses I can justify a higher price for the convenience.

    As far as the pricing structure being higher for V9 than the previous versions, since we need to buy runtimes for each user: hey, this new version is a major upgrade from V8. The ability to read and write to native SQL databases from the desktop and to build forms against these tables is awesome. Some of the other new features are great improvements as well.

    It is a shame that the roll out of a such a major advancement in capabilities is clouded by all the (in my opinion, warranted) criticism over the new runtime model.
    Jim Coltz
    Alpha Custom Database Solutions, LLC
    A5CustomSolutions.com
    [email protected]

    Comment


    • Re: New Run Engine Question

      Richard,

      I personally feel that the SQL Connectivity is a huge feature and warrants a higher price. You mentioned in the OEM:

      # Designed for single-user, DBF file applications that don't require SQL connectivity.

      Since you are able to disable the SQL connectivity, perhaps you can offer a lower pricing for the per seat run time licenses for the many users that do not need the functionality of the SQL.

      I have clients with a 10-user and others with a 20-user runtime. They fall into the same scenario as mentioned by DaveM. They also have NO need or use of the SQL connectivity, but perhaps would want to benefit from the other new features available in V9.

      I feel they would think that the current run engine pricing of 599 and 999 is a bit high since they would only be taking advantage of a small portion of the additional features without the SQL. They would have major issues with that pricing if they can no longer put a 10 user license on 15 computers in their office as it allowed them the flexibility of being able to use whatever computer is most available to them at the time they needed to access their Alpha application.

      At the same time, I do have clients that use the SQL connectivity and would like to take advantage of the new SQL features. They probably would not have any issue at all with the current run engine pricing. They would, however, have difficulty with the current pricing if they lost the ability of being able to install the runtime on unlimited computers restricted only by the number of concurrent users that could access the application at a time.

      I understand the need for the per seat licensing as this does resolve the issue of the long time problem of people using the runtime licenses as they were NOT intended to be used. However, this does cause a problem with those that used the licenses correctly but could install them on unlimited computers.

      Perhaps instead of a license per computer restriction, Alpha could create something that would have a license per connection restriction? Just thinking out loud here :)
      Cheryl
      #1 Designs By Pagecrazy
      http://pagecrazy.com/

      Comment


      • Re: New Run Engine Question

        Very well said Cheryl.

        Comment


        • Re: New Run Engine Question

          I completely agree with the concerns voiced here. While the new "active-link table" is a major plus for folks like me who are forced to integrate applications with other database files like Oracle, Access has been doing that for a couple of versions. This should be a feature available to all and has been on the feature list forum for a while.

          It seems that Alpha is aiming at much bigger customers than the base of existing customers with the new licensing arrangements. This is a dangerous marketing strategy in that the base of existing customers (I think) are folks who are running smaller apps as compared to the SQL server and Oracle installations which may have 1000's of users. Alpha has served that niche very well and I hope continues to do so in the future. However, by offering the "premium" things we've been asking for for ages (active links to foriegn database tables, improved browser capabilities, etc) only in a premium product model, the emphasis seems to have switched. It will take years to penetrate the large app market.

          I would like to respectfully suggest that an alternative strategy might be to offer two products - a web-development product which focuses exclusively on web apps and a desktop version which has the bells and whistles without any capability of doing web apps. Rarely, I would think, would a devleoper offer both platforms. The development is completely separate and so should the development platforms.

          FWIW,

          Dave Volgas, MD
          small developer for very specialized research apps
          David A. Volgas, MD

          Comment


          • Re: New Run Engine Question

            Dave

            An excellent idea IF the pricing is right for developers.
            If It Works First Time, There's Something Wrong!!!

            Comment


            • Re: New Run Engine Question

              I appreciate you taking the time Cheryl to lay out the issues as you see them and we will be looking into possible ways to respond positively
              thanks!
              Richard

              Originally posted by Cheryl Lemire View Post
              Richard,

              I personally feel that the SQL Connectivity is a huge feature and warrants a higher price. You mentioned in the OEM:

              # Designed for single-user, DBF file applications that don't require SQL connectivity.

              Since you are able to disable the SQL connectivity, perhaps you can offer a lower pricing for the per seat run time licenses for the many users that do not need the functionality of the SQL.

              I have clients with a 10-user and others with a 20-user runtime. They fall into the same scenario as mentioned by DaveM. They also have NO need or use of the SQL connectivity, but perhaps would want to benefit from the other new features available in V9.

              I feel they would think that the current run engine pricing of 599 and 999 is a bit high since they would only be taking advantage of a small portion of the additional features without the SQL. They would have major issues with that pricing if they can no longer put a 10 user license on 15 computers in their office as it allowed them the flexibility of being able to use whatever computer is most available to them at the time they needed to access their Alpha application.

              At the same time, I do have clients that use the SQL connectivity and would like to take advantage of the new SQL features. They probably would not have any issue at all with the current run engine pricing. They would, however, have difficulty with the current pricing if they lost the ability of being able to install the runtime on unlimited computers restricted only by the number of concurrent users that could access the application at a time.

              I understand the need for the per seat licensing as this does resolve the issue of the long time problem of people using the runtime licenses as they were NOT intended to be used. However, this does cause a problem with those that used the licenses correctly but could install them on unlimited computers.

              Perhaps instead of a license per computer restriction, Alpha could create something that would have a license per connection restriction? Just thinking out loud here :)
              Richard Rabins
              Co Chairman
              Alpha Software

              Comment


              • Re: New Run Engine Question

                Originally posted by Jim Coltz View Post
                This simple distinction between what the runtimes have historically been to what is now being presented is what is the most troubling to me. Perhaps Alpha can look into offering a "floating license" that works the same as the original runtimes.
                That would be nice, but the problem with that is this:

                Platinum allows you to export a lot of settings etc. very easily between different databases, projects etc. With DBF tables, they could enforce the amount of concurrent users of any given DB very easily, but with Active Link Tables to SQL databases, this is simply not possible, because the users connect to an SQL database rather than to a centrally stored DBF file... so you could easily get around the concurrent user limit, as there is no way for Alpha to keep track of that with SQL database active link tables...

                What *I* would like to see is, not for myself but for those (the majority it seems) who have long used A5 to write multi-user DBF based apps, a modification of the OEM "No SQL" RT that is split into:

                1) To have a basic, "neutered" RT engine shipped with A5, and thus the ability to create single user DBF only exes built into A5 Platinum... Full stop. Because let's face it A5 is handy for writing little programs or monitor apps too... and it would be a GREAT incentive for new programmers too.

                The more commercial apps out there will still be needing multi-user RTs, so I doubt that a lot of folk out there would be "ripping Alpha off" (or getting rich quick) with single user DBF only apps written with this...

                2) A cheaper than the per seat, multi-user "No SQL" RT model along the same lines as is currently the case with V8, because without the SQL functionality you can still keep check on the amount of concurrent users etc...

                On top of that, keep the "full whack" client server SQL-enabled RTs that are necessary for Enterprise solutions....

                Comment


                • Re: New Run Engine Question

                  I think that Alpha needs to address the question of how are current apps deployed. It seems that most users now either 1) develop web apps which make the runtime issue moot or 2) deploy the RT on whatever machines it is needed on for input, with a limit on the number of concurrent users.

                  The major sticking point, I think is that if you have a high number of input stations despite having a low number of concurrent users, then it is prohibitive to buy a license for every station. The choices under the current licensing arrangement are to deploy using the web (which is not possible for many of us who work under the auspices of a much larger enterprise IT department who takes years to deploy Office 2007, much less a WAS server) or to limit the number of input stations where data can be entered.

                  I personally don't care how the problem is solved, but I don't develop web apps and can't realistically put up my own web server, so I'm stuck limiting the number of input stations we use.

                  To illustrate the point, we currently deploy the A5v8 RT on 11 machines in 3 buildings in the hospital. Research nurses enter data close to the source of that data rather than fill out forms and bring them back to the office to enter into A5 there. However, the total time a user is connected to the database during the day may only be 2-3 hours. Therefore a 3-user license serves our needs very well.

                  If there is a low-cost solution to the above scenario, I'm all ears. Otherwise, we have to adjust the workflow quite a bit or move to a different product.

                  Dave
                  David A. Volgas, MD

                  Comment


                  • Re: New Run Engine Question

                    David

                    we are looking into this scenario
                    thanks
                    Richard Rabins
                    Co Chairman
                    Alpha Software

                    Comment


                    • Re: New Run Engine Question

                      Thank you Richard. BTW, Happy Easter!!!
                      David A. Volgas, MD

                      Comment


                      • Re: New Run Engine Question

                        the same to you!

                        Thanks
                        Richard Rabins
                        Co Chairman
                        Alpha Software

                        Comment

                        Working...
                        X