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

A few clarifications please before I take the plunge

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

  • A few clarifications please before I take the plunge

    Hello Alpha community:

    I am new to this forum and not an Alpha user yet. I am in the process of deciding if I should go with Alpha Five. I have read parts of the Users manual but am still unclear about a few points. So, I would appreciate it if I can get clarifications to the following points.

    About deploying a DB on a small network (assume on 7 client machines)
    1) If I understand correctly the way it is done in A5 is as follows (without getting into too much details):
    - create the DB using A5 standard
    - create a network version of the DB using Runtime
    - create a dummy DB using A5 standard
    - place the network version on a machine (server)
    - install Runtime on each client machine using Runtime for 10 users
    - install the dummy DB on each client machine
    - To open the db from a client machine: start Runtime which will open the dummy db which in turn will open the application on the server.

    If I missed something or misunderstood the process, please correct me.

    2) I understand that with Runtime the user can only use the DB: ie add/modify/view/print/ records, view/print reports, query/sort records, etc.. but cannot modify the DB itself in anyway, which is great. So the question is: if I install A5 standard on an 8th machine or on my laptop and open the master db on the server, would I be able to do development work like modify or create tables/fields/formulas/scripts/reports/browses etc... while the the users are using it or would that corrupt the master DB?
    If I go with A5, the 1st versions of my DBs will most likely need to be refined several times later down the road as my skills at using A5 improve.
    My question is: will this have to be done after office hours and weekends or is there in Runtime or A5 Standard a feature (or perhaps a process by Alpha experts) that can minimize after hours work? Is there a difference between a Runtime for "packaged" application and a Runtime for "custom" application that can help in this sense?

    3) Does the machine that hosts the master DB need to be a real server machine with Windows Server or would a dedicated Pentium V with Windows XP be enough to do the job (note: clients are small/mid size businesses; no SQL, just A5 DBs, no Web apps).

    4) Cost of ownership: All I need to purchase is A5 Standard and Runtime; my clients will not have to purchase anything from Alpha Five. Is this correct?


    Random questions:

    5) If I change the name of a table (or field or script), will I have to change the name in every place the table is referenced in the DB or will A5 do it automatically?

    6) Is there a list of Don'ts (kind of "to stay out of trouble with A5 do not do the following....")?

    Thanks in advance for any feedback.

  • #2
    Re: A few clarifications please before I take the plunge

    About deploying a DB on a small network (assume on 7 client machines)
    1) If I understand correctly the way it is done in A5 is as follows (without getting into too much details):
    - create the DB using A5 standard
    - create a network version of the DB using Runtime basically this is the same as the previous step
    - create a dummy DB using A5 standard Yeah, sorta but not required
    - place the network version on a machine (server)
    - install Runtime on each client machine using Runtime for 10 users
    - install the dummy DB on each client machine Sorta - see above sorta and next comment
    - To open the db from a client machine: start Runtime which will open the dummy db which in turn will open the application on the server. Starting the runtime won't automatically start the dummy db. If a dummy db is used, it's just used as a "place holder" until you open the main db on the server and run the network optimize routine. In my opinion, dummy DBs are much more useful for generic apps installed at remote locations by unknown users. For local apps where I could easily initialize each workstation, I don't think I'd bother with a dummy app.

    If I missed something or misunderstood the process, please correct me.

    2) I understand that with Runtime the user can only use the DB: ie add/modify/view/print/ records, view/print reports, query/sort records, etc.. but cannot modify the DB itself in anyway, which is great. So the question is: if I install A5 standard on an 8th machine or on my laptop and open the master db on the server, would I be able to do development work like modify or create tables/fields/formulas/scripts/reports/browses etc... while the the users are using it or would that corrupt the master DB? You can do this and I have done it but it's probably not the safest thing to do. If you're careful it's perfectly safe. But if you change things regarding the structure of the table(s) it might cause problems. For example, if you change the order of the fields for some reason or delete/modify indexes then your users are likely to experience all kinds of weird happenings. (Personally, I don't recommend ever changing the order of your fields once the app is in production. I do change field sizes or add new fields but I never delete them, move them, and almost never change their type.) If you have major changes to make, I recommend working on a copy of the db and testing it thoroughly before moving the changes to the production version. On the other hand, if all you do is add/delete/modify layouts, you can do that all day long on the server and it will have no affect on any other users who are running with a network optimized workstation until you update the network optimize number or otherwise cause them to refresh their network optimized workstation. Also, changing table structure or indexes requires exclusive access to that table which means (a) you can't do it until all other users have exited that specific table and (b) your other users would get errors if they try to access the table while you are working on it.
    If I go with A5, the 1st versions of my DBs will most likely need to be refined several times later down the road as my skills at using A5 improve. Well, duh!:D If you don't do that, you're much better than the rest of us! I still often feel like a beginner after only about 16-17 years of working with Alpha products. And I'm sometimes shocked at some of the dumb things I did with my older code.
    My question is: will this have to be done after office hours and weekends or is there in Runtime or A5 Standard a feature (or perhaps a process by Alpha experts) that can minimize after hours work? You really shouldn't need after hours work but you may end up doing some anyway. Just make your changes, Is there a difference between a Runtime for "packaged" application and a Runtime for "custom" application that can help in this sense? Not really. There might be some differences in the details of how you handle it but that's all. A local, custom application usually allows you a bit more freedom (carelessness?) in how you handle updates.

    3) Does the machine that hosts the master DB need to be a real server machine with Windows Server or would a dedicated Pentium V with Windows XP be enough to do the job (note: clients are small/mid size businesses; no SQL, just A5 DBs, no Web apps). Most of my clients don't have a "real server" but I do recommend something better than a $400 machine with limited memory and a slow hard drive. If you have a lot of users a dedicated server may be more reliable.

    4) Cost of ownership: All I need to purchase is A5 Standard and Runtime; my clients will not have to purchase anything from Alpha Five. Is this correct? Yes, sorta - assuming you are using the RunTIME and not the RunENGINE which is required if you want to both read and write to SQL databases. If you are selling the same app to many customers, that can be done with one copy of the runtime. However, if you are selling custom apps to various customers, each customer should be paying for their own runtime. Of course, it doesn't matter whether they purchase it themselves or you purchase it and include it in your charges to them - or give it to them for free if you feel so inclined.:D

    Random questions:

    5) If I change the name of a table (or field or script), will I have to change the name in every place the table is referenced in the DB or will A5 do it automatically? IF I understand your question - No, the DB won't do it automatically. You will have to change the name in everyplace you use it in your main application but the workstations will automatically update when the network optimization is refreshed as long as you don't change the name of your main application file - the .adb file. You can change names of tables, fields, and scripts but why bother? I don't recommend it only because of the likelyhood of missing a change somewhere. Just today I decided to use my Ord_head_CanSave script in the OnSave event instead. A name is only a name. You could call a script intended for the "print invoice" routine the Write_to_xyz_file script and it would still print the invoice. In cases like that where I change the use of the script (rare but it has happened a couple times), I simply add a comment line at the top to indicate when, why, and what the change was.

    6) Is there a list of Don'ts (kind of "to stay out of trouble with A5 do not do the following....")? Probably - but nobody has taken the time to write them all down. Most of them are nit-picky things specific to special situations and not really generic issues. Some of the things I do are because I had to do them in previous versions and they may or may not be required now. But they work and are generally safer so I keep using them but I really don't list them for anyone because I don't know if they are necessary anymore. In fact, I probably couldn't just sit down and list them. It's probably more accurate to say that sometimes I remember that certain things are required in certain circumstances and sometimes I don't remember until the customer calls with a complaint - and sometimes even then it takes me awhile to figure it out!

    Each version of A5 is generally backward compatible but there are often minor differences that can require you to change some code somewhere.
    Last edited by CALocklin; 09-20-2008, 10:35 PM.

    Comment


    • #3
      Re: A few clarifications please before I take the plunge

      You ask a lot of questions. Here's a skeleton answer set.

      1) Note that I reworded your phraseology and assumptions, so read this part carefully:
      • create the DB using A5 standard
      • place the DB on a machine (server)
      • install Runtime on each client machine using Runtime for 10 users
      • run a very simple code snippet to "bootstrap" the DB on each client machine (this will create a "shadow" copy of the DB on each client machine)
      • To open the db from a client machine: start Runtime with a shortcut which will open the shadow db which in turn will access the data files on the server.
      2) You can work on parts of the db while others are using it on the 8th machine. I used to do this everyday in my company. I would work on my Client shadow and copy the changes to the server as needed. What you can't do "live", is change the db structure and indicies. That part you have to do after hours. (Note: some people express horror at this M.O. - but I did it for years, no problemo.) Of course, all the usual backup and safety precautions apply.

      3) You don't need Windows Server 2003 or whatever. XP will do the job nicely.

      4) no comment - I'm sure others can chime in.

      5) Basically, if you change a table name Alpha will not propagate that forward. You have to manually change the name everywhere. So get that part right on Day One!

      6) Probably lots. I'm sure others can chime in.
      Peter
      AlphaBase Solutions, LLC

      [email protected]
      https://www.alphabasesolutions.com


      Comment


      • #4
        Re: A few clarifications please before I take the plunge

        Since you're a "newbie" and asking about a list of don'ts, here are my thoughts on Naming Recommendations. It's probably the only "list" I have.

        The important thing is to understand the "why" of my recommendations. If you decide to apply the standards differently, that's fine with me. If you get in trouble because you applied them wrong, it's not my problem.:) (Actually, you probably won't "get in trouble" no matter what names you use but things may not be as easy as they could have been.)

        One thing that I don't believe is in that document is the idea of naming layouts with a "number" plus description. This can make it much more "foolproof" when referring to a layout. For example, if the report name is just "Mfg_code" then it is likely to be referred to as the "manufacturing code report" on the phone. However there might be other reports that also deal with the manufacturing code or they might actually be talking about the FORM that deals with the manufacturing code. If instead the report is named something like CLR09_Mfg_code, then references to it will likely be to "report CLR09" and that is a very distinct and non-confusing reference. One of my customers came up with this and I really like it. It has reduced the confusion noticeably. This particular name tells me it's based on the Customer List or a set starting with the Customer List (CL) and it's a report (R) and the description part is rather obvious.

        <soapbox>One thing that should be obvious once you read my recommendations is that I HATE blank spaces in any names. There are too many good reasons NOT to leave blank spaces yet many people do it "just because". More than one person has told me, "I just like to do it that way". I just don't understand the concept of knowing there are many good reasons not to do something and then doing it anyway just because you want to or because it's what you're used to doing. I have not seen any good reason to leave blank spaces in names other than the very lazy excuse that, "I'm not used to using the underscore character so it takes me extra time." Just use it 10-20 times and you'll get used to it and be able to do it without looking.</soapbox>

        Comment


        • #5
          Re: A few clarifications please before I take the plunge

          Thanks guys for your feedback. Much appreciate it.
          If I make the switch, I'll have tons of questions; A5 is so rich in features and different from what I am accustomed to. I just hope that the Alpha community is forgiving in this sense.

          Comment


          • #6
            Re: A few clarifications please before I take the plunge

            I think you will find this one of the most forgiving boards around. We've all been there.

            Comment


            • #7
              Re: A few clarifications please before I take the plunge

              Hi Gaby,

              Welcome to Alpha. This is a great message board, I can tell you that Alpha and this board have changed my life.

              We look forward to all your questions. It is very strange that after a short while you will be answering other new comers. It gives you a nice warm feeling when they thank you for an answer that you yourself had a problem with.

              Couple of bits of advice, try and do a search first. Sometimes the answer is right here in front of you. Sometimes it might not be the right answer, but you might pick up a tip for future use in another situation.

              The other thing to try and remember is, to ask one question in each new thread you start. There are a number of reasons for this, the main one being that it makes it easier for others to search and understand how a problem was resolved.

              Good luck with your use of Alpha and we look forward to seeing some or your work.
              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


              • #8
                Re: A few clarifications please before I take the plunge

                Thanks guys I already feel at home.
                Don't worry Keith, I'll do my homework before posting my questions. I just finished watching one of the videos on how to create reports, I am very pleased with what I saw.

                Comment

                Working...
                X