> Thanks for your response! I've couple of supplementary questions, but
> first a
> bit more info about our database needs.
>
> - We have an external file that is pointed to be a field in a table
> record.
>
> - Tables contain other metadata associated with the external file.
>
> - The application allows the user to open/edit the external file --
> analogous to a editing a document in a Word processing program.
>
> - During that time, changes in the metadata (or the external file for
> that
> matter) by other users shouldn't be allowed as it will cause
> problems.
>
> - Editing is an ongoing option that is incremental and could take
> hours.
>
> Now for my concerns about the dummy-update approach.

I don't know the exact process of editing this external file. What process
edits it? Is this external file accessible by others? a mulit-user
environment?

>
> Let's say Open Shape starts with a dummy update (I don't mention "begin
> transaction"
> below because under ODBC the update starts a transaction, but I don't
> think
> using an explicit SET TRANSACTION would make a difference)...

DBConn.BeginTrans
yes it would since you then need to commit it or roll it back under your
procedure.

>
> User1::DummyUpdate
> User1::ReadShapeData
> .
> .
> . User2:DummyUpdate - Fails, as it should.
> .
> User1::COMMIT
> <== User3:DummyUpdate - Succeeds.
> User1::DummyUpdate fails. .
> . .
> . .
>
> Now any attempt by User1 to do a COMMIT will fail, unless User3 does a
> ROLLBACK I suppose. In other words, User1 opens a shape, does some

or commit.

> mods, and, if the timing is just right, loses access to the shape in
> the middle
> of an editing session.

you don't start editing until you get a succesful update and you have the
record to yourself until you commit or rollback so you can't loose your
edits.

>
> Additional issues...
>
> - Under ODBC there is just one transaction on a connection; User1
> could inadvertently COMMIT this operation, without subsequent
> DummyUpdate, while COMMITing a different shape or
> updating a completely un-related table. (Does having a connection
> per shape sound like a good way around this?)

If you choose to use the default transaction, then yes. But that's a little
bit "lazy" of you to not be specific about your transactions. You choose to
being then, and then commit of roll them back depending on your application
logic. The ODBC driver does not impede this process.

>
> - Once you have a shape open, you have an active transaction which
> may persist minutes, hours, or even longer, depending on user
> behaviour.
>
> Is my thinking completely off the wall?

It's always best practice to keep the transactions as short as possible
within your ability.
As I said, there may be a benfit to committing, and then dummy updating
again to achieve the lock. Is there a chance that another person could chose
to and get a lock in the plsit second of the commit update cycle?
Alan

>
> Regards,
> Lee
>