How would YOU do it ?

[aschone]

Re: How would YOU do it ?

I personally do not use this method. However I have a "test" database that I opened, it exists on my C:\ drive. I ran that code I posted earlier in the interactive window. The only errors I get are related to the global variables that form is looking for but do not exist in my test database. Otherwise the form opens and I can see and navigate the records.

I tested this in version 11 Developer, Build 3036-4040. I do not know why you are getting the error "not found".

Marcel may still be on holiday. Besides others may have the same question and this may be beneficial to them as well.

[Tom Cone Jr]

Re: How would YOU do it ?

It's entirely possible to store both databases and all supporting tables for each in a single folder. This can be handy when the two databases need to "share" a common table. I've been doing this for years in an application originally written in vers 4.5 of Alpha Five. All that's necessary is to use separate names for each database, and then avoid duplicating table and set names (except where they're to be "shared").

[Ray in Capetown]

Re: How would YOU do it ?

No disagreement with that Tom - but the Form MUST exist in whichever DB you open it. That's my point. And that was the original request as I understood it. Not to have ANYTHING extra residing in the various transaction databases and still be open whatever in the master records database.

I commented on the statement
"Aye, that code is how you open a form that is not in the current database."

Opening forms with shared tables is fundamental to many apps of mine. I share also with other types of DBF database systems.

[mronck]

Re: How would YOU do it ?

For me this doesn't open a form that is not in the current database

form.view("Cust@c:\drive_g\acdps\cust.dbf")
ERROR: Not found

where it is in another. Would be an interesting idea - can you explain how you have it working

Besides why are we bothering when Marcel Onck is not.

Come'on Ray... cut me some slack. It's Christmas.... not in SA?

[mronck]

Re: How would YOU do it ?

The reason why I asked this is, that sometimes it is handy to have something like "building blocks" from which you build your "package of functionality" by grabbing different databases that each deliver a part of the requested functionality.

Furthermore, that does not have to be restricted to your own databases (of which you know how tables, forms etc are named) but assume the following:

I take a specific database from Tom, which handles sales for a shoe salesman. He wants to extend his functionality. So I just add my database to it, which delivers that desired functionality. Now, we only would need to add "lines" from Tom's database to my additional database.
This could be done by opening forms in different databases. It IS an option...... I simply do not see any other, do you?

It would be nice if Alpha's control panel had somewhat more options. Like creating directories inside it. Then you could simply add a directory in the control panel at every section (tables, forms, reports, code) and insert the objects etc from the other database in it.

I do not object to having all in one database, but I object to having it all on one pile. It does not help keeping an overview when the numbers of tables etc are adding up, and the systems are getting more complex.

I guess this is all about "how to organize things in the best way".

[Ray in Capetown]

Re: How would YOU do it ?

oh O K ! Slack it is then. BTW since when do real programmers stop for Christmas? But then I'm Jewish.

This could be done by opening forms in different databases. It IS an option...... I simply do not see any other, do you?

It could be done - if Alpha could open a form from another database. It can't.

You can simulate that - A5.load() with some minor changes to make it seamless.

Try it.

[aschone]

Re: How would YOU do it ?

To be honest I am not sure what part of this thread I am missing. I keep seeing the question of how to open a form from another database. I keep responding that this possible and have provided the code for how to do it. However I also keep seeing that you cannot do this. So I put together a sample database that has 1 table with 1 form. On the form is a button that will open the form from a second database.

Either this is what is being asked for or I have missed the point completely.

[Ray in Capetown]

Re: How would YOU do it ?

Hi Andrew
I took a look, see and know what you have shown. You are referring to "opening a form using data from another database"

But remove the form from one database and try open it from the other - you cant.
I think its the symantics - in the sentence "open a form from another database" is meaning "open a form that is in another database, not in this one"
If you have a solution to that lets try.

Added:- the idea Marcel seeks as I understand it is a hierarchy, not to have to duplicate every form in every/any "higher layer database"
Nor code or anything else - just inherit all via some link to the database below.

[Tim Kiebert]

Re: How would YOU do it ?

I think its the symantics - in the sentence "open a form from another database" is meaning "open a form that is in another database, not in this one"
If you have a solution to that lets try.

Isn't that exactly what Andrew has demonstrated. Open the ADB_a adb. In it is one form, Frm_a. On that form is a button that opens Frm_b. Frm_b is no where to be found in the ABD_a database/project/workspace. It is in a completely different database/project/workspace ADB_b.

[Ray in Capetown]

Re: How would YOU do it ?

CORRECTION !!
Andrew is 100% CORRECT.
Mindblowing I must add.

The statement made by me was not tested to the full extent of its implication.
-------------------------------------------------------

[Ray in Capetown]

Re: How would YOU do it ?

Isn't that exactly what Andrew has demonstrated. Open the ADB_a adb. In it is one form, Frm_a. On that form is a button that opens Frm_b. Frm_b is no where to be found in the ABD_a database/project/workspace. It is in a completely different database/project/workspace ADB_b.

WOW and huge apologies Andrew.
I was so obstinately stuck on the belief that the form was needed for this in the first place from that example.
I now cleared form and data from B. and then entered into the IW

form.view("frm_a@"+a5.get_path()+"\tbl_a.dbf")

and it opened.

So all you need in the current database is the code that knows where the form is.
That is - for me anyway - a revelation thanks for your persistence and Tim's
and again humble apologies. Next round is on me.

[aschone]

Re: How would YOU do it ?

No worries Ray. I am glad we are all on the same page. Now to broaden the scope some more. You can call scripts that exist in another database.

'Date Created: 02-Jan-2013 03:53:28 PM
'Last Updated: 02-Jan-2013 03:55:20 PM
'Created By : andy
'Updated By : andy
OPTION STRICT
OPTION ENCRYPTED_TOKENS
ON ERROR GOTO ERR_HANDLER

DIM vMsgC as C
vMsgC = "Hello world" + crlf() + a5.Get_Name() + crlf() + "This script is in database 'B'"
ui_msg_box("Hello",vMsgC)


END
'-----------------------------------
'Error handler
'-----------------------------------
ERR_HANDLER:
DIM vErrN as N
DIM vMsgC as C
vErrN = error_code_get()

vMsgC = "Error # "+ vErrN + crlf() + error_text_get(vErrN)
vMsgC = vMsgC + crlf() + "Script: " + error_script_get()
vMsgC = vMsgC + crlf() + "Line #: " + error_line_number_get()

trace.writeln(vMsgC)

ui_msg_box("Error", vMsgC,UI_ATTENTION_SYMBOL)
vMsgC = ""

END

Using the database copies uploaded previously copy this script into database "B". Save it as "Hello_World".

Then from database "A" execute this command.

script_play("Hello_world@"+a5.Get_Path()+"\adb_b.alb")

The biggest concern with this is that the script will run in the context of database "A". This is demonstrated by line 2 of the script " a5.Get_Name() " which will return the information related to Database "A".

To wrap it up we can call forms and scripts that reside outside of the current database. This is one method of achieving the results that Marcel was asking for.

[Ray in Capetown]

Re: How would YOU do it ?

Very interesting.
I just received the feedback - been without an ADSL line on and off for days, thanks to the sole telecoms carrier here, owned largely by govmnt, Telkom (there is a website Hellkom)
I will play around with it - yes that would largely cover his request.

Thanks
again.

[SNusa]

Re: How would YOU do it ?

Hi Andrew,

Yes, that is an option, but then you get one "organic" database. I understand that option. But I am looking for a more "slick" solution for instance where the master database would function as an add-on to the other databases or something like that. So you will not "cloud" the transparency/organizational structure from the transaction databases (the others) with the complexity of the "master" database. The control panel of Alpha Five is severally limited with regards to the organisational structure as is, and I am looking for options to add complete databases to one database without making it even more complex in the control panel by added tables, forms and reports. I do not know if it even can be done....

The reason why I asked this is, that sometimes it is handy to have something like "building blocks" from which you build your "package of functionality" by grabbing different databases that each deliver a part of the requested functionality.

Furthermore, that does not have to be restricted to your own databases (of which you know how tables, forms etc are named) but assume the following:

I take a specific database from Tom, which handles sales for a shoe salesman. He wants to extend his functionality. So I just add my database to it, which delivers that desired functionality. Now, we only would need to add "lines" from Tom's database to my additional database.
This could be done by opening forms in different databases. It IS an option...... I simply do not see any other, do you?

It would be nice if Alpha's control panel had somewhat more options. Like creating directories inside it. Then you could simply add a directory in the control panel at every section (tables, forms, reports, code) and insert the objects etc from the other database in it.

I do not object to having all in one database, but I object to having it all on one pile. It does not help keeping an overview when the numbers of tables etc are adding up, and the systems are getting more complex.

I guess this is all about "how to organize things in the best way".

Bingo - I've had these exact thoughts, over and over again..... One thing worth mentioning regarding the mixing of databases are "missing variables." If you call the external form, and that form relies on any "global variables or higher" (declared elsewhere ie: not in that form or in the underlying tables/sets) you're going to need to add them back in. And the correct place (as I recall from testing/debugging a5) is NOT from within the code itself... They need to be set "at a higher level" via the "V" in the toolbar. If initiate/declare them them via a form event via code, you may experience issues, as they are not initiated "soon enough" for "a5 internals." I also suspect other things (such as saved queries etc. used in the form may present other issues.) ~ Regardless, without "building blocks" (as suggested above) built into a5 itself: I'll bet you'll encounter some strange and unexpected results at times!!

Incorporating both a"Building-Block modular design" & "Control Panel with directories" into a5 are great ideas by the way! The "a5 program" is way too complicated and has grown well beyond the present organizational limitations of the a5 CP. (Especially since the web components were "bolted on.")

Note: You can also place the two databases in two directories (parallel to one another @ the same level) to keep them organized & separate. But since a5.get_path() won't work in this instance, you'll have to either "hard code" or declare a variable to the path instead.

[SNusa]

Re: How would YOU do it ?

"Modularized Integration"..... I believe there is already a way to do this, built into a5!

Just had another idea.... how about using the dropping (and re-adding) of databases? You don't have to first "drop a database" to "add it" to a different database..... And you can "re-add" to your hearts content if necessary without fear of breaking anything.

Providing you have access to the existing database (aka original "component"), unless I'm missing something - This is all you'll need (presumably) to do.....

1.) Develop the new database "component" up to the point where it needs "integration."
2.) Now "integrate it" by doing the following.

• Copy this "new component" (the entire database directory) into the "original component" directory. (so the "new database component" is self contained in it's own directory)
  
  
• Open the "original component" and from the table/set tab, select "Add Table." (find the new table in the "new database component" directory ~ the warnings should not apply.)

BAM! ~ I think it may be as simple as that! As for functionality I'll bet this is also a good way to "modularize integration!" (But check with "the pro's" first.)

Modularized..... And the best part is (as far as I can tell) is: Any changes you make to the "new database component" can be made either from the "original database" or from the "new database component!!! (This includes new browses, forms, reports, tables, etc.) Because when creating & editing objects based on "added external tables" (from within the new database) you are actually making changes into to the "new database components!" (I'm not suggesting doing any of this without checking with AlphaSoftware first though!)

The only "caveat" here is scripts. Scripts (created under the "new database") will have to be imported for use in the new "original database." (But Alpha has made that a straightforward and simple process.) Also, when writing scripts, using relative paths & at in all cases, avoid "hard-coding" so that at least your "new components" are designed "portable" from the get go....

Note: I also suppose it might be possible (in certain instances) to switch things around and make your new database the "root" depending on the circumstances. ~ But only if you're "building something big" around something that is presently "small and simple." I particularly don't like the thought of moving the original directory, even if everything else worked. ~ Because based upon prior experimentation, it would be like "playing with fire!" (I submitted several confirmed and fixed bugs regarding "hard-coded" directory/file structure bugs over the past few years.)

PS: A year or so ago, I did some extensive "testing" with the "drop and add tables" features/capabilities. I came to the conclusion that this great feature is one of the least understood (and utilized) capability built into a5! (It is also a fabulous solution for creating multiple comprehensive [virtually "one-click" restore-able] versions of tables/sets (along with their associated underlying objects like forms & reports etc.....) The only problem is that when you use the internal backup/restore functions like (zip, export and backup) from the a5 menu, they all ignore dropped tables.) Apparently they work under the assumption that a dropped table is: "JUNK!") ~ So I use different 3'rd party "zip" tools for backups. This is a relatively SIMPLE FIX that could be addressed by adding one persistent checkbox (in these routines/tools!)