Calling another APP

[Thomas Henkel]

This may be a newbe question, but we have a very extensive application running in A5 ver 1.02. We have purchased ver 4, but are stymied on how to proceed. In ver 1.02, we didn't need to define all of the databases available to an application, but, it seems that they need to be defined in version 4. We thought that calling a separate application for each phase of our business would be the easiest solution. version 1 had an "app_run" command. We don't see it in version 4. How can we accomplish this.

code is as follows:


DIM SHARED ACCESS AS N
DIM SHARED A_APP_CURRENT_PATH AS C

IF ACCESS=1011 .OR. ACCESS=839 .or. BETWEEN(ACCESS,15,20)
new=app_run("g:homemkrhomemkr.apd")
submit_let(new,"ACCESS",ACCESS)
else
new=app_run("g:homemkradmin.apd")
submit_let(new,"ACCESS",ACCESS)

END IF

Our thoughts are to have the main application and form just perform the security check, then pass control off to the department-specific application.

Any help would be appreciated.

Tom Henkel

[Peter.Greulich]

Ver. 5 is supposed to have a "Load Database" command. You might be able to do it in ver. 4 using a sys_send_keys command - provided users have access to the controlpanel.

[Thomas Henkel]

How often do you want users to have access to the control panel? This is a massive collection of applications and databases, something along the lines of 15-20 separate functions(applications) and between 500 and 1000 tables and sets. This cannot be left up to a user to navigate through teh control panel. We have over 250 users, some on remote connections through a CITRIX server. We need an interface as simple as version 1.

[Tom Cone Jr]

Check out the message threads:

Question for Selwyn, 6/2/2000

Switch database from form, 7/25/99


The consensus online is that there is no way to use one app to run another. Instead, the paradigm is to develop a single 'database', then use a main menu form to branch to different modules in the application.

-- tom

[Thomas Henkel]

It just seems so rediculous that something which worked so well under release 1 was abandoned with these newer versions.

[Peter.Greulich]

I agree. But the good news is that ver. 5 will have that command reinstated.

[CALocklin]

Thomas,

My first impression from reading your initial message was that you are defining a separate database for each DBF file. I hope this is not the case because it is not necessary! The definition of "database" was changed between version 1 and version 4. (I think it was first changed in version 2 but I'm not sure.) In V1, a database equalled a DBF file. In V4, a database is a collection of DBF files.

Having said that, I have had some luck with a simple sys_shell command to open another V4 database:
sys_shell( "d:a5v4alpha5.exe G:A5v4ptrackerptracker.adb" )

HOWEVER, I later abandoned it as unnecessary and even confusing. If applicable, I just put all the necessary tables and sets in one database. Where that doesn't make sense, I just let the user open another application.

[CALocklin]

Oops! I forgot to fix the command to allow for the HTML. Here is the corrected command:

sys_shell( "d:\a5v4\alpha5.exe G:\A5v4\ptracker\ptracker.adb" )

Or, more generically:
sys_shell( "A5 program> "Application file> )

[Thomas Henkel]

Cal,
I think that the best way for anyone to invision what we do is to let you see our main app. Please remember that this is ver 1.02. Once you see what is going on, you might understand my frustration. We are a county government agency. We have applications that handle client information as well as employee information. I can't see how we could create an application that could hold all of our tables and sets. Our main signon screen captures user information and passes it throughout the system with the user. we need to keep this information flowing throughout all of our applications. see attached

[Tom Cone Jr]

Tom, adapting an existing system to a new way of doing things is never easy, and can certainly be frustrating... especially if the existing system works fine. This is often expressed by folks migrating their apps from Alpha Four to Alpha Five, for example.

In your case, you main menu apparently permits the user to 'call' a variety of applications, and then return to the main menu when each ends.

This is how my own system works in Alpha Five, but I don't call other applications, I call other forms, which call forms... and so on. At startup I, too, collect information that is stored in a series of global variables, which are available to any of the forms and scripts in the system.

If you want to convert your system using Alpha Five vers 4, I'd recommend you begin with a dummy table to which you can attach a main menu form. Convert one 'application' at a time, adding them all to the same folder and database. Start with the smallest ones to give yourself a bit of a break on the learning curve.

Good luck.

-- tom

[Thomas Henkel]

My concern with adding everything into one enormous main application is one of maintenance. If the forms and reports tabs would cascade off of the table and set tab, then it wouldn't be such an overbearing task. In many instances, we have forms for different sets with the same name. How would one distinguish which one they are working with? I am wholeheartedly for upgrading to a more powerful Alpha5, but maintenance, at this point, would be a complete nightmare. We have over 250 users tied into this system daily. What sort of network and workstation problems are we going to encounter when loading such an app?