The import is with user interaction. No non UI jobs on that.

Moving to a server - a dream.
Means to start from scratch. There is stuff in it that must be from the days of dBase.
0tier logic. Just that I have pushed CA's between the tables and that. To much on frontend. Newer stuff is on business level. Nothing on database (except a handler for new records or PK will fail)

The validation in write - this should double up the validation on frontend, then. My customers would not accept a form filled and then rejected because of some stupid validation. To have this infront of write is mandatory (as far as it goes, with this imports).
I know about the pros and cons - but, .. , I get money for not beeing SAP.

The problem is that is it an anyway problem.

What I think about in the moment.

I can do a meta table, where I can simply mark a distinct table as dirty (counter timestamp) and force the requery of a CA from that.
I would be possible to "register" the CA to a central object that watches the meta. Like a DBMS.
I control the apps that access the DBC, anything goes through CA so I can move it there.
And if the watch object sees a change it can notify the CA.
This can go as far as any change to a table or only the major ones like imports.


>>If I could express myself better I think I would not have those questions ... sigh.
>>
>>Just ask questions, it helps. :)
>>
>>It is vague (+.+)
>>
>>No the preloads are per form. But once in forms lifetime.
>>Some of them even do not have a requery, but this I can manage through the inheritance. (I can query the CA's for that and force the requery)
>>
>>The data I'm changing might notice that they have new data on disc. That's not the problem. This is clasic multiuser.
>>But they are depending on other stuff - and that is imported. Say a child can have a specific flag only set if the parent is in a specific state.
>
>Controlling the embolded part is something that might be delegated to back-end RI. pro and cons, but if data is important, DB RI as base and biz logic for easier user interface. And if you have to work with a vfp data backend, you might consider pessimistic locking put in effect in one of the hook methods of the first table updating drilling down the needed CA's. Or drill down comparing the timestamps, either only at tableupdate() or regularly at a long-running timer. amd make those parts an extension of the CA class used for that project, either working on each record write hook or at the multi-record hook level by something like:
>select s.pk, s.timst, from (this.alias) as s join (this.table) as t on s.pk=t.pk and s.timst # t.timst into arrray ...
>
>or perhaps even filter s for those records changed or with changes in children - flagging children changes something I did, by creating dependencies on the CA's to have bubble up automatics.
>
>>For now parents state will not alter whil form is living. Now it might change. So I can not longer set this flag. My TABLEUPDATE will not reach the parent - it changes nothing there so how get I noticed about the change? And argh I dislike to read the parent every time I change a child ....
>
>having such checks done will not take enough time for the user to notice, if that is your worry.
>
>You can always force an update by altering a dummy field, which would include the parent record in the list of data writes, or just have the timestamp check described above done. While the whole picture is still unclear, you HAVE to get your validation rules specced in WRITING - otherwise your customer will get unpleasant surprizes.
>And then you should get a clear picture at which level such validation is done and what risks or entry complication is entailed.
>
>If you go for DB based RI (better safe than sorry), do not use the vfp own stuff, but the one of the Hentzenwerke books, which is SQL based and much easier to grok. This is also one of the time points where you should discuss porting to a real SQL DB backend with your client. The more often validation logic is needed by different programs and currently implemented in different layers and now automatic import is added, all the more reason to consolidate such logic in the DB to be CERTAIN no rogue/old/faulty program writes wrong data.
>
>>
>>The import changes many places at once.
>>
>>Bulk operations for the import?
>>But this would create even worse situations, where the data is not fitting together for a longer time. My fears are with the normal multitable updates on record level but table by table?
>>A bulk update needs data gathering and synch before - I can not change anything in this thime or I run in circles
>>
>>I feel lost
>
>Can those updates be piped though a non GUI version of your program or can you rewrite non biz layer forms to accept alternate input from file?