>>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.
Words are given to man to enable him to conceal his true feelings.
Charles Maurice de Talleyrand-Périgord
Weeks of programming can save you hours of planning.
OffThere is no place like [::1]