Documentation / How-To - Missing Pieces

[BobT55]

Here in my early stages of learning Alpha Five there appears to be very little information, both in the WIKI and the message boards (as far as my searches are concerned) in the following two areas -

Toolbars - Specifically in their potential use as a menu for an application and generally in editing them other than customizing one by deleting existing pieces.

Named Connection Strings - Documentation (What's new for Version 9) seems to state that you can change data sources by editing the connection string, but there is no example showing how, for example, to change between a local table (.dbf or .accdb) and SQL (whatever flavor). From the message boards it reads like you need to change every table, browse, etc. to change data sources. Which is it???

Does anyone know of any good information on either of these subjects? Any help would be appreciated.
- Bob

[Ted Giles]

Re: Documentation / How-To - Missing Pieces

Bob, there is a ton of information regarding Toolbars in the Local Help

In case you heven't got it, here's the Wiki link.
http://wiki.alphasoftware.com/How+to...Custom+Toolbar

Connection strings are a little more complex.
http://wiki.alphasoftware.com/Create...nection+String

If this doesn't answer the question to your satisfaction, suggest you post a specific Q to a Forum of your choice.

[praymond]

Re: Documentation / How-To - Missing Pieces

I too am recently new to Alpha5 and developing. Here's some useful information on what to understand when creating connection strings and the pitfalls of lessons learnt. Unfortunately I didn't get to Connection Strings 101, but I wish I did as it would have saved me some frustration in learning a useful lesson when creating connection strings.

When creating connection strings uses a generic name. DO NOT USE words or text in the name of connection string that refer to the database or source because they can be misleading and create problems much later when you move from a test environment or staging environment to a live environment. If you fail to follow a generic naming convention what you end up with is a named connection string that isn't what it appears by its’ name and can confuse.

Good naming convention: Isolation Procedures

Poor naming convention: localhost MySQL Isolation Procedures

The above poor naming convetion became misleading when I moved the staging area database from MySQL to SQLServer2008. The name didn’t reflect the data source and I had the choice of leaving the connection string name as is but changing the connection string. This changed what database my application was looking at and did the job but its’ name wasn’t appropriate. If I created another connection string with a name that represented my SQLServer datasource every grid and every lookup (and probably a few other things as well) would have to be changed. not a good choice.

So when changing where web components look all that is required is to change the connection string from your staging area database to live database, so use a generic connection name.

When you develop your database and transfer it to another database in the same database type or different database type (e.g. move from MySQL to SQLServer2008) all you have to do is change the string and all your grid data connections and Lookups will point to the new source.

[Steve Wood]

Re: Documentation / How-To - Missing Pieces

My advice, name your connection string "conn" and never anything else unless you absolutely have to. Don't make the name have any significance because your situation will change, and then the name is confusing. If you ever have to merge two databases, if the connection string is named conn in both, then it is easy to merge the database AND the A5 web application. If they are different, then you have to forever live with at least two connection string names for the same application, or go through the labor of changing the connection string in one of your applications (a real chore).

And since you will be typing your connection string value thousands of times as you build your application*, you want a name that is short, easy to remember and and means something. "Conn" means connection string, "Isolation Procedures" does not mean connection string, it means your application name.

You should not name a connection string "Isolation Procedures", just name it "conn".

There is an IADN Best Practices Guideline at http://alphadevnet.com/downloads/Alp...Guidelines.pdf.

*Connection string is selected for grids, etc and typed in for xbasic and sql statements

[BobT55]

Re: Documentation / How-To - Missing Pieces

Steve,

In my case I use multiple connections strings. For my desktop active link tables app I use one (conn_data) to connect to the data source be it an Access database file or SQL and another (conn_settings) to connect to an Access table for local variables (user settings).

My real question is how switching from "conn_data" (Access) to "conn_data" (SQL) would be managed as there seemed to be conflicting info on how the peocess is handled. Since the named connection string stays the same is it as easy as changing it to point to the alternate data source or are there further impacts (and manual changes) to be aware of?

In Steve Workings message HERE it sounds like programmatically changing the string (keeping the name) is not currently possible and that lots of manual changes need to be made yet coming from Access I could dynamically repoint my linked tables on the fly. Not so in Alpha?

Thanks for your help. I'll re-read your guide document again as a refresher!
- Bob

[Steve Workings]

Re: Documentation / How-To - Missing Pieces

Bob - let me clarify since you've linked another message into this.

The current situation I have is that I've inherited an extensive application, mostly built-out and full of references to a single connection string.

Now the customer is saying "I want multiple users and sites, and each will have their own data source." That's why I was wondering if I could "spoof" the existing named connection string to use variable data sources. I've decided that I cannot (and probably should not anyway).

Had this application been designed to manage this multi-tenant, multi-database scenario from the beginning, it could have taken advantage of the relatively new A5 feature of Dynamic Connection Strings. The reason I cannot use them in this application is because they require the very specific naming convention, and I'm not about to try to find and replace every instance of the existing connection string with the new dynamic name.

Lesson here is to think ahead about what your application may grow into, and be sure you keep the path as clear as possible for such expansions.

[Steve Workings]

Re: Documentation / How-To - Missing Pieces

Now I'm going to reply to my own post, and raise the question especially to Steve Wood:

I wonder if, in the interest of maintaining maximum flexibility and room for future growth, if it might be a good idea to always name a connection string as if it were a dynamic string, e.g. DynamicConnection_Conn.

It still needs to be fed it's definition at startup time, but it really doesn't matter whether the definition gets changed at all after that. But, and here's the key: it could, and that is a potential barrier that is knocked down at the beginning.

[Steve Wood]

Re: Documentation / How-To - Missing Pieces

I think that is a good idea for the reason you suggest if you can live with the limitations - ONLY for grids - not available for xbasic, Dialogs or reports. Personally I cannot live with that and would find another method.

I wonder if you could somehow spoofed the connection string value in a5_application.ai at runtime (a5_application.ai is where the sql connection string alias is stored). I know that alias and connection string is put in memory but I don't know if each user gets a separate copy in memory when they first hit the website, or if there is only one copy of that alias and connection string in memory and everyone shares it.

I also wonder if you can build separate instances of the web server and alter the connection string per instance. I don't see any option for that but it sounds plausable.

Another (not so horrible) option is to create multiple a5_application.ai files and then totally duplicate your entire application for each client to login. You'd maintain one copy in Developer, and use File Watch to automatically update the other copies of the application when you publish a change. You can ensure their respective a5_application.ai files are not altered in the process.