Modular Database Design Question

[Peter.Wayne]

I know that a group of related scripts and functions can be put into accessory database files or into .aex files to be loaded by a main database, but I was wondering whether the same can be done with groups of tables and sets. That is, if you have some large, unwieldy application with multiple sub-modules, can the tables and sets (with their accompanying layout designs) for a module be loaded when the module's database is attached to the primary database? Right now it seems to me that the tables and sets have to be added to the primary database, otherwise they will not appear.
Any one of you have any insight on this? It seems to me that this would be a great advantage for those of us who suffer from application waistline expansion.

[csda1]

RE: Modular Database Design Question

Peter,

Of course you know we can add and drop tables/sets from the database file (adb) under program control, and we can also look at the tables/sets associated with other adb files, so yes, I believe you could dynamically combine and separate individual applications.

There might be some path implications in code and a few expressions that would need to be made path independent.

The adb files would basically be the list of supporting tables/sets for each submodule.

Regards,

Ira

[Finian Lennon]

RE: Modular Database Design Question

Peter:

Would it be absolutely necessary to add the sub-module components to the main database?

Assuming that each module's components are stored in a known sub-folder of the main, it should be possible to address them all directly without ever adding them to the primary database.

mainpath=:A5.Get_Path()+Chr(92)
mod_path1=main_path+Chr(92)+"MOD_Path_a"+Chr(92)
f=form.view("billing@"+modpath_1+"bill.set")

will open the billing form. I don't know how widely you could apply this, but is should work.

I remember reading a couple of messages from Tom Henkel outlining how hw dealt with some of these types if issues within their multi-module app.

Finian

[whanigsberg]

RE: Modular Database Design Question

The new A5.load() method may be relevant since it closes the current database and loads another. I haven't done much with it but in principle it should make it as simple to jump around among databases as it is among sets or tables.

Bill

[JohnZaleski]

RE: Modular Database Design Question

Ira,
I've never had to use the add and drop tables/sets from the database file (adb) commands.
Does that actually write to the adb file?? If so if you are running optimized is it happening to the shadowed adb? If you are not running optimized does it write to the adb on the server and change it for all??
I'd not be too comfortable doing that regularly with lots of tables on an app with a lot of users.
John

[Peter.Wayne]

RE: Modular Database Design Question

What I was looking for is a "one-click" method to add a whole adb file and its associated tables and sets to a database, much the way that an addin can be added by putting an .aex file in the \addins folder. I don't think there is any one-click method and clearly some extra programming is required, particularly in network optimized settings.
One solution would be to provide a cr-lf delimited text file of tables and sets in the upgrade, along with the version number of the upgrade. The autoexec for the application would check for the file -- it could be as simple as "upgrade.txt" -- and if found, it could then add the tables and sets as Ira suggests, attach the library to the database (there must be a method somewhere to do this), set the application version to the new version, and then delete the upgrade.txt file.

now -- does anyone know the xbasic method for adding a library to a database?

[csda1]

RE: Modular Database Design Question

John,

Those are good questions.

As I recall, it definitely modifies the adb of the master when not shadowed.

When shadowed, I believe it would change the shadowed adb file, but I'm not really sure. This would definitely be a minor operational change that could change between releases unless established as a method that developers are using and maintained by Alpha Software as such.

If anything, it should change the shadowed version, but I can see reasons why it may not, as a shadowed table is really just a pointer.

You bring up some real valid points. On the other hand, there are many methods that allow direct manipulation of a table, whether or not it's in the ADB.

But that does not address Peter's problem. If you consider a "dummy" adb file that get's loaded one time by all of the installed "modules", then you are doing it as an install, rather than a live modification, and I would consider this an acceptable method in that case

Regards,

Ira

[csda1]

RE: Modular Database Design Question

Peter,

Peter Wayne wrote:
-------------------------------
now -- does anyone know the xbasic method for adding a library to a database?


Create an AEX file that is the same name as the adb file. If you want, there is an Xbasic method to combine multiple AEX libraries into one, the method name escapes me for the moment.

Regards,

Ira

[JohnZaleski]

RE: Modular Database Design Question

Ira,
I agree that in an install it would be acceptable.
I thought Peter was looking for a way to break a very large app into modules and have the ability to add all the module tables and sets with a simple command.
John

Peter,
Your install method sounds okay. I would think it would be easier to have an already attached dbf file that is overwritten. It's records would show tables not yet added.After adding the tables the records could be deleted.
John

[CALocklin]

RE: Modular Database Design Question

You could use string = load_adb_def( DatabaseName, Mode ) to get a list of all the tables and sets then use File.copy() and file_add_to_db() to add them in.

Here's some test output from running load_adb_def() in my interactive window:
?load_adb_def("H:\A5v5\_A5v5_std\Std_code.adb")
= h:\a5v5\_a5v5_std\capitals.dbf
h:\a5v5\_a5v5_std\std_code.dbf
h:\a5v5\_a5v5_std\app_codes.dbf
h:\a5v5\_a5v5_std\test.dbf
h:\a5v5\_a5v5_std\zipcode.dbf
h:\a5v5\_a5v5_std\states.dbf

I couldn't find a "one step" method for copying a table but there is an A5_duplicate_set_files() function that might work - but read the description first because it appears to have some limitations. However, although I'm guessing it's got to be there, I couldn't find anything for copying a table that handled it in the background without popping up a dialog box. However, I'm sure you can figure out a way to copy the files once you have the name and path for the table/set.

The question with the al* files would be what do you want to copy? I'm not sure you could attach the library but I wouldn't be surprised to find there's a way - this would certainly be easiest. However, attaching the library probably won't bring over any saved settings, etc. that may be stored in the .al* files. Separate code might have to be created to get at them. (I know the later can be done because I created my own AIMS_Drop_setting_old() function when the A5.Drop_settings() wouldn't work. It's called "old" because my new version lists all available settings in a dialog box and lets you pick which one to drop - I got tired of forgetting what settings I had created.)

I can't find a one-step method for copying over all the scripts if you wanted to do that but the EXPORT_SCRIPTS_AND_UDF() and IMPORT_SCRIPT_UDF() functions could at least make it much easier. You might have to run the export manually but you could probably do the import as part of the overall "import database" function.

I can't help wondering if it would really be worth all the effort. (This from a nut-case that created an improved Xbasic script formatter with optional indent/spacing/capitalization settings just to see if he could do it!)