Create application independent of the data it will use?

[Al Buchholz]

Re: Create application independent of the data it will use?

John

Here is an older posting of code to redirect tables.

It may be the type of thing that you are looking for ..

http://msgboard.alphasoftware.com/al...ad.php?t=22937

[csda1]

Re: Create application independent of the data it will use?

Hi John,

I'm having a little trouble with this "data dictionary" thing. Does every file the program (form, reports, etc.) access HAVE to be included in the data dictionary; and if it does, perhaps you could do some wizardry by changing the info in them to access a different file in another location...?

The table/set data dictionaries contain everything that is not the data, indexes or memo fields (if any). That means layouts and operations for the most part. The database's dictionaries (*.al* files) contain all the global code, toolbars and menus

To use a data dictionary object, it must be in the data dictionary of the table/set that you want to use. If it is not in the data dictionary, you must copy the needed items from a template table's dictionary to where you need this (You could also store the binary of these objects in files and other places, but this is beyond the abilities of most people here)

Except for XDialog boxes, you can not create dynamic forms or other layouts (for the most part), that were not created in the layout editors, but you can design them to have conditional objects that give the impression of being dynamically generated.

You can, however, create all the operations via code, and in fact, my operations tab in the control panel is normally empty in a distributed app.

[Davidk]

Re: Create application independent of the data it will use?

David

This looks promising, especially if you can add files on the fly such as you have described. So, if I understand correctly, when you want to use an external file, you let them select it, add it to the database so you can use the forms, browses, layouts, etc., designed for it, then remove it when they are finished working with it.

If I read your code correctly, that's what your doing, right?

Assuming that the only thing you would have to do is refer to the file by an alias instead of the actual name, then this might work.

Yes, I`m letting the user select a drive and folder, then based on that select I`m adding the files in that folder to the database. I don`t really call the Alpha5 Table name an alias - it`s just the database name to me... but that name does refer to a physical file on a drive.

I think this type of approach would work well for your type of app. You can `connect` to a set of client files, work on them, disconnect then, then choose another set to work on. You could keep all client folders in one main AllClientData folder. When you want to take them with you, you can take whole AllClientData folder, or just the Client folder within the AllClientData folder.

David

[Peter.Greulich]

Re: Create application independent of the data it will use?

The ONLY way to create this kind of an app is to maintain the data files for each client separately.

Don't agree, but I understand your point of view.

The key is to refer to the files selected via an alias so all the forms, browses, layouts that you've created will be independent of the file selected. There in lies the magic.

Any thoughts?

Since Alpha doesn't provide an alias, I suggest you use a sleight of hand. Your main application uses one set of tables. Use a rename/copy operation w. xbasic to hot swap client tables between the main app and the client folders. That should get you the desired effect.

[jjfcpa]

Re: Create application independent of the data it will use?

Yes, I`m letting the user select a drive and folder, then based on that select I`m adding the files in that folder to the database. I don`t really call the Alpha5 Table name an alias - it`s just the database name to me... but that name does refer to a physical file on a drive.

I think this type of approach would work well for your type of app. You can `connect` to a set of client files, work on them, disconnect then, then choose another set to work on. You could keep all client folders in one main AllClientData folder. When you want to take them with you, you can take whole AllClientData folder, or just the Client folder within the AllClientData folder.

David

David

I think it's time to get down and dirty and give it a try. With the great responses on this thread, I think I'm ready to move forward. I've purchased a copy of the Platinum version to begin learning how A5 works.

Any suggestions on getting better acquainted with A5. I've seen some of the videos and I've also seen the tutorial book that you can purchase. What would you suggest?

[jjfcpa]

Re: Create application independent of the data it will use?

Don't agree, but I understand your point of view.


Since Alpha doesn't provide an alias, I suggest you use a sleight of hand. Your main application uses one set of tables. Use a rename/copy operation w. xbasic to hot swap client tables between the main app and the client folders. That should get you the desired effect.

Sorry, I didn't mean to imply that my way was the only way; it's just that I've done it the other way and encountered many more "file management" issues. Of course, the way you suggested would certainly work, but we feel that keeping the files independent is easier for the enduser to work with them. Yes, we've run into issues with that also, such as, they lose track of a file and ask us what happened to it. We actually wrote a routine to search for all files on any drive connected to their computer just to deal with this problem. Certainly wouldn't happen if all their files were in one database.

I do appreciate your contribution to this thread and hope you will continue to offer advice. Such as... what's the best way to learn A5? I'm ready to start working with it ... up close and personal.

[Davidk]

Re: Create application independent of the data it will use?

I don't know how different the coding language is from what you're using in FoxPro. I'm coming from many years in Access and I'm finding it a bit frustrating... the syntax of some of the xbasic stuff is just odd. The xdialogs with embeded code is hard to wrap my mind around.

Just dive in and try to get things done that you need done. My app checks a table to make sure it exists when the app starts. If it's not there then I pop up a message and allow the user to find the data tables and then attach them. I hadn't written that part yet, but your original question prompted me to start looking at it... wasn't too hard to put in place.

Usually takes me hours to find the right way to do something but I have no deadlines so I don't really care.. have to learn it sometime.

The action scripting is very powerful so use than when you can.

Have fun,

David

[martinwcole]

Re: Create application independent of the data it will use?

I'm sure there are a lot of good reasons for making this so complicated, but (and please forgive me) I don't see why.

I've been doing this with an app for over 2 years, where the client has about 200 nurses/techs/therapists that float between hospitals, clinics, assisted linving centers, etc. We keep each facility in a separate folder, and each folder has a copy of the app.

When I make a change to the app for the client, I always make the change in the app for the first facility, and then via a script update all the other facilities to match.

Is simple and works like a charm.

[jjfcpa]

Re: Create application independent of the data it will use?

I'm sure there are a lot of good reasons for making this so complicated, but (and please forgive me) I don't see why.

I've been doing this with an app for over 2 years, where the client has about 200 nurses/techs/therapists that float between hospitals, clinics, assisted linving centers, etc. We keep each facility in a separate folder, and each folder has a copy of the app.

When I make a change to the app for the client, I always make the change in the app for the first facility, and then via a script update all the other facilities to match.

Is simple and works like a charm.

Martin

Thanks for confirming what I assumed would be a fairly easy solution to my way of doing things. The only thing that seems somewhat wasteful is that in addition to the data in each folder, it would also contain other files that are the same across all data folders.

So would this include the data dictionary, which would include the forms, reports, layouts, etc.?

It just seems that you should be able to specify a data dictionary that defines the structure of the tables, but allow the data tables to be stored elsewhere?

If I'm starting to comprehend this, according to the files types shown in this link

http://support.alphasoftware.com/alp...File_Types.htm

All of these need to be in the same location, but you can change the location on the fly to accommodate multiple data locations?

[martinwcole]

Re: Create application independent of the data it will use?

The support files dd* for a dbf file contain the layouts, operations, long field names, and field field rules for that particular dbf.

The support files se* for a set contain the layouts for the set - but not the field rules, long file names, etc.

The support files are normally small and in today's environment insignificant. If you made 25 forms, 25 reports, and 25 operations for one table, then the support files will be a bit larger.

Given that portability of a single client is an issue, I would totally just go with the way Alpha normally manages things. Especially since you are new to Alpha.

As for splitting the clients, in your case and mine I completely agree. Accounting apps for a single client are tough enough to begin with without mixing clients. If we were writing an app like Alpha Sports, I would completely disagree.

If you were an advanced Alpha user, you might gain a little bit of space with a lot of finagling, but it would most likely almost totally destroy portability. But even then I doubt the return would be worth the time it would take.

I switched to Alpha from another language in 1998. In the beginning, I continued to think like the first language, which I had been using for about 15 years, and found it quite frustating to say the least. It took me about 6 months to make the adjustment, to learn to think "Alpha." Once I got used to things, I was awestruck at how much faster I could develop in Alpha from the first language. A screen that I might work on for three weeks, I could do in maybe 3 days. And now (10 years later) I could do it in 1 day.

[jjfcpa]

Re: Create application independent of the data it will use?

The support files dd* for a dbf file contain the layouts, operations, long field names, and field field rules for that particular dbf.

The support files se* for a set contain the layouts for the set - but not the field rules, long file names, etc.

The support files are normally small and in today's environment insignificant. If you made 25 forms, 25 reports, and 25 operations for one table, then the support files will be a bit larger.

Given that portability of a single client is an issue, I would totally just go with the way Alpha normally manages things. Especially since you are new to Alpha.

As for splitting the clients, in your case and mine I completely agree. Accounting apps for a single client are tough enough to begin with without mixing clients. If we were writing an app like Alpha Sports, I would completely disagree.

If you were an advanced Alpha user, you might gain a little bit of space with a lot of finagling, but it would most likely almost totally destroy portability. But even then I doubt the return would be worth the time it would take.

I switched to Alpha from another language in 1998. In the beginning, I continued to think like the first language, which I had been using for about 15 years, and found it quite frustating to say the least. It took me about 6 months to make the adjustment, to learn to think "Alpha." Once I got used to things, I was awestruck at how much faster I could develop in Alpha from the first language. A screen that I might work on for three weeks, I could do in maybe 3 days. And now (10 years later) I could do it in 1 day.

Thanks Martin. Your reply is very reassuring. I'm willing to give Alpha a try just based on messages like this. Developing client based apps like this is much different than developing a custom app for a client, so just knowing that someone else has done it puts my mind at ease.