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
Devcon 2020 Goes Virtual! LEARN MORE >

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

OEM Run Engine (for developers building commercial, packaged software)

Collapse
X
Collapse
 
  • Page of 2
  • Filter
  • Time
  • Show
Clear All
new posts
Previous 1 2 template Next
    #16
    Re: OEM Run Engine (for developers building commercial, packaged software)

    Hi Richard

    B) you are building multi-user applications or applications where you do need SQL connectivity then, the Regular Run Engine is the way to go. In this scenario the cost per seat for the application(s) that you build is

    $60 per seat if bought as part of a 10 pack
    $50 per seat if bought as part of a 20 pack
    $40 per seat if bought as part of a 50 pack
    $34 per seat if bought as part of a 100 pack
    Just sitting here thinking about this current Run Engine plan that has been laid out. In real world implementation, let's say I wanted to buy a 100 pack to optimize costs for my clients. How would I as a developer roll this out so that I want to allocate 10 of my 100 to be for client A, 20 for client B, etc.? Do I get 100 license codes?

    I would like to throw a vote in for concurrent user pricing instead of per seat as some others have also indicated. As many have said, it is not uncommon to have the app on 30 computers but at any one time only 20 people can access the app. I have one client whose building is 75000 square feet. It sure makes it nice for someone to get on any pc in the whole building instead of having to walk 300 yards to their desk.


    I am sure the last day or so has been tough for you and I hope your business situation allows you the flexibility to alter some of these policies if you choose to do so. As I mentioned in another post, none of us know Alpha's business situation and what you need to do price/qty wise to have a successful business. I am sure no one here wants Alpha to lose money - no business can survive doing so. You have a great product. I hope some of these Run Engine issues can be worked out so everyone can be happy.

    Regards,

    Jeff

    Comment

      #17
      Re: OEM Run Engine (for developers building commercial, packaged software)

      Richard said

      "The problem appears to be that you dont know how many you will sell till you actually start marketing.
      So the question is why do have to buy Alpha Five v9 Platinum and the OEM runengine at the same time?
      Why not buy the Alpha Five v9 Platinum product for $299 initially, build the app or a prototype and then show it off to potential customers to gauge market demand."

      I ask, how do you send a demo out without an OEM runtime?

      I agree that different size runtimes could be bought and re-used with a number of clients, that was how it was sold to us developers. Having to buy a new runtime for multi users does make sense.

      I have developed a small application that I have no idea how well it will sell. Possibly for no more than $100 each. For me to lay out $600 for the OEM before I sell a single copy will be a hard pill to swallow. Ok, so I might sell 6 copies and get my money back, but I've still layed out for V9. I would be happy at $200 for the OEM, at least I would feal I had a fighting chance of making a profit.

      As I understand it the Single seat License does not need online activation, does that mean the same license key will allow the same runtime to be used on multiple single machine? If that is true them the OEM idea is blown out of the water.
      Regards
      Keith Hubert
      Alpha Guild Member
      London.
      KHDB Management Systems
      Skype = keith.hubert


      For your day-to-day Needs, you Need an Alpha Database!

      Comment

        #18
        Re: OEM Run Engine (for developers building commercial, packaged software)

        Originally posted by jkletrovets View Post
        Hi Richard



        Just sitting here thinking about this current Run Engine plan that has been laid out. In real world implementation, let's say I wanted to buy a 100 pack to optimize costs for my clients. How would I as a developer roll this out so that I want to allocate 10 of my 100 to be for client A, 20 for client B, etc.?

        you can do exactly that Jeff
        Do I get 100 license codes?

        I would like to throw a vote in for concurrent user pricing instead of per seat as some others have also indicated. As many have said, it is not uncommon to have the app on 30 computers but at any one time only 20 people can access the app. I have one client whose building is 75000 square feet. It sure makes it nice for someone to get on any pc in the whole building instead of having to walk 300 yards to their desk.

        I believe we have a solution for this scenario - I will be checking in with the development team early in the week re this - thanks Jeff


        I am sure the last day or so has been tough for you and I hope your business situation allows you the flexibility to alter some of these policies if you choose to do so. As I mentioned in another post, none of us know Alpha's business situation and what you need to do price/qty wise to have a successful business. I am sure no one here wants Alpha to lose money - no business can survive doing so. You have a great product. I hope some of these Run Engine issues can be worked out so everyone can be happy.

        Regards,

        Jeff
        Richard Rabins
        Co Chairman
        Alpha Software

        Comment

          #19
          Re: OEM Run Engine (for developers building commercial, packaged software)

          Option C) Not mentioned - you are building multi-user applications or applications where you do NOT need SQL connectivity... I assume there are still people using the DBF format. I have been following the thread as it's of interest. I use multiuser, dbf. Not SQL at this point. One option that might be looked at is a different pricing schedule for DBF multiuser than SQL multiuser. Or..maybe have the runtime work as previous for DBF and change the licensing for SQL.

          Russ

          Comment

            #20
            Re: OEM Run Engine (for developers building commercial, packaged software)

            Originally posted by russ Boehle View Post
            Option C) Not mentioned - you are building multi-user applications or applications where you do NOT need SQL connectivity... I assume there are still people using the DBF format. I have been following the thread as it's of interest. I use multiuser, dbf. Not SQL at this point. One option that might be looked at is a different pricing schedule for DBF multiuser than SQL multiuser. Or..maybe have the runtime work as previous for DBF and change the licensing for SQL.

            Russ
            I have just suggested something similar in another thread...

            I can COMPLETELY understand why the concurrent user limited RTs are not an option with SQL-enabled apps, because the lack of a shared set of DBF tables (in a fully client-server setup) makes this impossible to control. Also, the export and import functionality for connection strings etc, and being able to copy forms across between DBF and active link tables, makes it impossible for Alpha to limit the amount of concurrent RT users...

            My suggestion would be to include - at no extra cost, and without needing to install anything on your machine - a "neutered" RT engine in A5 Platinum, which allows you to build single user executables using only DBF files, no SQL, no shadow database options etc... and whatever other limits are necessary to make this possible. This could be used for compiling demo versions of your apps for example, possibly with the option of a time limit built into the install maker (one can dream, right?)..., with active and passive link tables included as DBF files... Smaller, single user charity projects could also be done on this basis without needing any paid for RTs either...

            The RT pricing for the full SQL enabled client-server RTs can stay the same, that does make sense, but there should, just like there used to be in previous versions, be something akin to the V8 non-Enterprise, non-PLUS RTs, concurrent-user limited for creating multi-user apps using DBF files only, but able to use things like super controls, export to Excel and so on...

            Just my $0.02.... or $20... (Have nothing better to do than philosophise on this as our company is on holidays until Tuesday and typical delays in communication mean I probably won't get the V9 WAS until I get back from my holidays in early April now...)

            Comment

              #21
              Re: OEM Run Engine (for developers building commercial, packaged software)

              "Web applications

              If you are building web apps - we continue to have an unlimited number of users per server model. If you couple this with the new AJAX capabilites (and other web application building enhancements, it makes Alpha Five V9 PLATINUM a potent and very cost effective tool."



              There is obviously a "trust" issue going on here Richard. I think people are feeling that they have shown tremendous loyalty over the years, which has enabled Alpha Software to grow. Developers have invested significant money and huge amounts of time, and are now feeling that unless they upgrade to the new v9 for LOTS of money, they may be left in the dust with little support of v8 and earlier versions.

              You say that with web apps you get around the user limitation. But given the change in pricing model you have just released, I wonder if I can "trust" that you will not change that for the WAS at some time in the future. So should I continue to invest huge amounts of time and money in developing the WAS?

              Needless to say, the price structure for v9 concerns me as well!!

              Gary
              Gary S. Traub, Ph.D.

              Comment

                #22
                Re: OEM Run Engine (for developers building commercial, packaged software)

                Richard,

                seems like there is a workable model which I saw one time in a program called Biblioscape. That model required installation of the runtime on a network server. The app ran directly on the server and thus could limit how many concurrent users it serviced. The advantage is that the user doesn't have to install anything on his computer, the model would work even in a thin client situation, and Alpha could certainly protect their investment. I dont know how complicated this would be to write, but seems like a "right" solution.

                Dave Volgas, MD
                David A. Volgas, MD

                Comment

                  #23
                  Re: OEM Run Engine (for developers building commercial, packaged software)

                  I was going to upgrade, but I see it's not time yet.
                  Last edited by neil_albala; 03-29-2008, 02:41 PM.

                  Comment

                    #24
                    Domain specific OEM Run Engine license with active-link-table support:

                    Let me start a new thread.

                    Comment

                      #25
                      Re: Domain specific OEM Run Engine license with active-link-table support:

                      Originally posted by neil_albala View Post
                      Let me start a new thread.
                      Don't bother! THis is an "old" thread, just take a look at the new licensing and stop fretting about an outdated description!!!!

                      The new OEM RT Engine DOES allow active link tables but is priced on a case by case basis (cos someone marketing huge Enterprise apps with Oracle or SQL Server back ends probably should pay a bit more than someone who has a small business app they want to convert to use mySQL etc!), the equivalent to what is described in THIS thread is now just $399 and at the moment when you buy A5V9 developer copy you get the single user re-usable RT for just an extra $100...

                      (removed broken link)

                      And here's for the first time it seems a COMPREHENSIVE explanation of the different RT options, with each case catered for and the rules made quite simple to understand (as opposed to the previous short explanation and vague wording): (removed broken link)
                      Last edited by Lenny Forziati; 06-02-2023, 02:47 PM. Reason: removed broken link

                      Comment

                      Previous 1 2 template Next
                      Working...
                      X