A few clarifications please before I take the plunge

[gaby_h]

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.

[CALocklin]

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.

[Peter.Greulich]

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.

[CALocklin]

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>

[gaby_h]

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.

[CALocklin]

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.

[Keith Hubert]

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.

[gaby_h]

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.