From inside a Maintain app on a server with many users that has a large Focus database,
I want to create a temporary focus database *by user* from specific data from the large DB,
update that temporary database from that same maintain
then be able to update the large Focus DB from data in the temporay DB by user.
All from within the same Maintain app.

Any suggestions? FYI - Each user has their own folder on the server or can I just use EDAtemp?
How does Maintain find that temp DB by user?

This message has been edited. Last edited by: Kerry,

Prerrequisite: you have to have a master file for the temporary database, otherwise maintain will not be able to do anything with it. That also means, you will have to have the data file itself before the maintain starts.
I think this can be arranged.
Maybe it is possible to do this:
Create a small maintain without data files that calls a fex that reads the large database and creates the temp file from it. The fex stores it in the temp area for the user that is calling the maintain. You can't have it store it in the edatemp, because the fex runs in a different edatemp directory than the maintain. When the fex is done, have the small maintain call the large maintain. At that time both master file an data file have been created. In the master file (using ther dataset keyword) you can specify where the data file is located, so you do not need a USE command.

Seems it might work.

Brad
I was able to do something like this with a flat file. One procedure created the flat file and then the Table used it as criteria. It uses the TEMPPATH command to know where the file is being written. You MAY be able to do something like this:

In your EDASPROF have:

FILEDEF SEL DISK SEL.DAT

In the parent Maintain have:

CASE SENDDATA
COMPUTE PTH/A256;
COMPUTE I/I3=1;
REPEAT OUTSTK.FOCCOUNT
Compute OUTSTK(I).CAT = "'" || OUTSTK(I).CAT ||"'";
Compute I=I+1;
ENDREPEAT
STACK CLEAR HTMLSTK
CALL WRITER FROM OUTSTK INTO PTH
EXEC TABLE1 FROM PTH INTO HTMLSTK
ENDCASE

Note, I added a PTH or Path variable. Now, the child Maintain writes the file, but also knows the path that it wrote to and passes it back.

MAINTAIN FROM OUTSTK INTO PTH
COMPUTE HTMLSTK.HTML/A2000;
COMPUTE outstk.cat/a15;
COMPUTE I/I3=1;
REPEAT outstk.FOCCOUNT
TYPE ON SEL "< COMPUTE I=I+1;
ENDREPEAT
COMPUTE PTH/A256 = TEMPPATH(256,PTH);
END

Now, the TABLE takes that path and can find the file that was written:

-SET &Q = &1 || SEL.DAT
FILEDEF SEL DISK &Q
? FILEDEF
-RUN
TABLE FILE MOVIES
PRINT TITLE BY CATEGORY
WHERE CATEGORY IN FILE SEL
ON TABLE PCHOLD FORMAT HTML
END
-RUN


This was for passing multiple selections into a Table, but you MAY be able to use it for a FOCUS file.

Mark

Brad

Are you using persistence, i.e. WINFORM SHOW form?

or non-persistence, i.e. WINFORM SHOW_AND_EXIT form?

Using persistent
Winform Show form

Brad

There is no direct way to achieve exactly this, but there is an indirect approach, which, as you are running persistent, will work.

The basic stumbling block is that Maintain needs to have the data available on start up. I was trying to locate some old code I had from way back, but couldn't trace it, however, from memory the process can be achieved using the agent directory. In pseudo code:

-> user selects data required from LARGE db
-> exec KEEP table extract focexec to retrieve data from LARGE and HOLD AS SMALL FORMAT FOCUS
-> exec KEEP table selection focexec to retrieve records for user from SMALL to choose from, can be combined with above.
-> display
[The extracted SMALL focus db resides in an agent directory, and this can be accessed by any exec'ed focexec, but NOT a call'ed maintain. KEEP is the default, but I use it. The exec causes a second agent to be used and it is here that the data in temporary files resides. At the end of the Maintain, or an exec DROP, the data will be removed]
-> user selects a record to change
-> exec KEEP table to get record
-> display
-> user makes and presses SAVE
-> exec KEEP modify with parameters to update SMALL

At any point, or prior to exiting
-> exec KEEP focexec to extract from SMALL and MODIFY into LARGE.

In my case I had a Save and a Commit button. The user had to understand that non-commited SAVEs will not be reflected until the Commit button is clicked. If I remember correctly I also added a column to SMALL to know if a record was changed / deleted / new.

Careful coding can construct a hierarchy structure for SMALL, otherwise FOCLIST is key or part of.

Hope this gives ideas, any variation on a theme of the above will work. The Maintain exec call is rapid and the users will be unaware of the slightly off-beat nature of the code.

Alan

First - thanks for the response.
I tried following your suggestion. A couple of points and question.

Currently,
I am running a large Maintain app w/ forms. It Exec's focexec's to extract data from a large Focus DB into stacks, displayed, changed and Call'ed other maintain apps then update the large DB.
When there are many simultaneous users running this one Case that has a a lot of I/O (deletes data then adds), the Focus DB is corrupted.

My idea at a solution:
I wanted to extract subsets of data from the large Focus DB -by user- and display it, update the smaller DB, then at then end of the user's session, update the larger Focus DB.

It is one Maintain. Can cases in that maintain see that smaller Focus DB via Exec's and calling maintains that update it?

Brad

The only part of the code that can see the SMALL db are the exec'ed focexecs.

What worries me now is that you are saying that the large FOCUS db is getting corrupt. If set up correctly that simply does not happen (apart from an index bug in 4.3.1 that was fixed).

Trying to work around a basic corruption issue is not an answer. Please talk to Mark and get the basics sorted before trying new approaches which may not fix the original problem.

Brad
Alan is correct. We should make sure that your SU is set up correctly. I am pretty sure you are issuing COMMIT statements after your updates so the database should stay current. Call in to Help Desk. We can make sure that your SU is correct (With SET COMMIT=ON) and trouble shoot if you are getting corruption.

Mark

Thanks everyone for your responses.

We have looked at tis particular case extensively. I agree in that the rest of the large maintain works but just this one case which performs deletes and adds. The DB is only corrupted when many users are using this particular maintain app.

I will open a case later this week and pursue it from there.

Thanks

One more thing we should consider?
Your opinions please....

This logic of this maintain app works. However, the problems arise when a larger number of simultaneous users are running the system.

When this particular case of the maintain app is run, a number of forms are open (I think 6 forms)and one of the forms has a larger number of objects on the form including a read/write grid.

Could it be a memory problem on the server?

The database is corrupted only when this particular case is run with -many- SU users. We removed the options for users to run this case and the app worked great for months. We made the case available, and in low usage times it worked. The usage peaked and the database became corrupted. There are several other "intense" I/O cases but those cases do not have more than 1 or 2 small forms open.

In general, if a form has a larger number of objects on the form (including a read/write grid), does this significantly require more memory on the server? (vs a a form with fewer objects)

Your opinion:
Should we try to re-write the app such that fewer forms are open simultaneously? Or should we be looking at the SU machine configuration?

Thanks....

Brad
Could it be that there are collisions in the data? If 2 users are trying to update the same record, there could be locking. That SHOULDN'T lead to any issues, but it could. Are you issuing COMMITs after the database interactions to free the locks? Is there anyway to retrieve fewer records so there are less interactions with the database?

If you would like me to trace the code, zip up the MNT and MAS files and e-mail it to me.

Mark

Yes I am using COMMITS immedaute after the updating the database using REVISE command.

Very, very rarely are SU users updating the same record(s). In the last data "crash", we are rather certain (but not completely sure), that just one user was accessing/updating the specific data within the FOCUS database.
(data is deliniated by hospital(key field) and then by departments(key field) within a hospital.

If I send MNT and MAS files, do you need data? Do you need EXEC'ed routines?

quote:

When this particular case of the maintain app is run, a number of forms are open (I think 6 forms)and one of the forms has a larger number of objects on the form including a read/write grid.

I believe it is considered bad practice to have more than one form open at any one time. There are standard approaches to ensuring that the navigation works leaving only one form open at any one time.

It could be that there is a data conflict within the users own forms that is causing an issue.

I have used the single open form approach for many years, and had no data related problems.

quote:

In general, if a form has a larger number of objects on the form (including a read/write grid), does this significantly require more memory on the server? (vs a a form with fewer objects)

Check the agent memory usage for the figures you get when running this. Maintain can use large amounts of memory if left uncontrolled. This varies with the forms and also the amount of data.

Alan - When this specific case runs where there is a delete and add to the database, I do have as many a 6 forms open, with one for containing manu objscts including a read/write grid.

I am aware of the technique of opening just one form at a time. I will try that.

In addition, the Maintain Wizard made a few suggestions about updating the database not using a REVISE command but a INCLUDE/UPDATE command instead that I will also try.

For the immediate time (and a quicker solution for us now), we are moving that function out of the current maintain (with forms) to a separate utility section of our app which is called from an HTML form.
The removing of this particular function to the HTML form is in testing. Unfortunately, we can not replicate the problem until we have a large number of SU users. But this delay will also give me time to try the Wizard's suggestion of the revise command and your suggestion of the forms.

CLOSED FOR NOW