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. 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 ....

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

The current handling is a two-decades-multi-developer nightmare. Don't ask. All I know is that a lot of processes trust that some data will not change. I have control over when data is written or force a requery. I programatical know what tables a CA is using and writes to.

What I think about now is to lock all major process (write, reporting, export) on application level for the time of import and force a requery afterwards. There are things implemented in the database and the app I possibly can use for it.

>Still a vague visualization for me - are your previously preloaded data validations something that should be unloaded into the DB layer as RI ?
>
>Even if not, in the order your current input biz logic CA approach currently validates changes in different tables you should be able to handle bulk changes - but carry out delete actions most of the time at the end, so that you have to schedule some bulk actions for each table, most often a cycle of add, change, delete bulk loads. M:N might need more thought in scheduling specific bulk actions sometimes.
>
>When lookup tables needed in RI-like manner are modified, an exclusive process is easiest and still often used today - otherwise perhaps you need to implement a virtual locking or some way to kick out users if the base records they are working with currently need to be modified.
>
>Perhaps more info on current handling would help - currently feel as if I am shooting into the dark or blindfolded - sorry ;-)
>
>regds
>
>thomas
>
>>>>I have a locking problem.
>>>>
>>>>Or at least no idea.
>>>>
>>>>There is a database that for now is filled via exclusive imports.
>>>>
>>>>The normal forms write through CA to tables, checking a synthetic timestamp (bound to the machine this is, but it normaly run on a terminal server) and changed fields, sometimes writing to multiple tables through transactions (the CA's build in is a bit a risk on that). It depends on pickup tables etc set by former import. The checks are on forms or business level, depending on use and how old the form is. The data to check is preloaded, because for now it is static.
>>>>This works pretty well.
>>>>
>>>>Now the customer likes to import the data in a non exclusive way.
>>>>
>>>>It's clear that I have to rewrite my import.
>>>>
>>>>But how do
>>>>I check data that I only read for changes, (but I can not read them on every update, that's to much data gathering on some)
>>>>lock the update if the lookups are changing by import
>>>
>>>Ouch... and the damn english is in the way. What do you mean by:
>>>
>>>- exclusive vs non-exclusive - is "exclusive" to mean "everyone get out of your apps while I import" or "the import has the rights to update whatever it wants"
>>>
>>>- lock - I have a feeling you don't think of record locking or table locking... Does "lock the update if the lookups are changing by import" actually mean "abort the update" or "keep the lookup tables locked while importing" or what?
>>>
>>>- checks - I assume you don't mean to write us a check :), but you mean validation. Correct?
>>
>>Hi Dragan,
>>
>>#1
>>Now the programm runs exclusive against the database - so everyone gets out
>>
>>#2
>>That feeling is right. I can do R-/FLock but this will not solve all problems. Also this is a two way problem, and I can not LOCK anything 95% of the day for nothing.
>>
>>#3
>>Validation.