Thanks for your help. I understand that that is the problem because if i do
a "change table" right before my "Save" it does the SQL Update (i can see it
in the Profiler). However, I'm still having the problem. I'm opening the
file using "change table" at the beginning of one function (and I know it's
locked because i tested it by trying to do "change table" again at the end of
the function). However, once I manipulate other data in the window, and (in
another function, not that that matters), do a "copy from window to table"
and "save table", it still has this problem, as if I lost the lock somewhere.
Is there anything else besides "save," "release" or "remove" that will do
this to me?
"David Musgrave [MSFT]" wrote:
> Table operations are covered in detail during the Dexterity Training, please
> contact your MBS Representative to register your interest in getting some
> The problem you are having is because you do not have a passive lock on the
> record you are saving.
> If you execute a save table command without applying a passive lock it will
> always attempt to create a new record and if it already exists it will
> produce a duplicate key error. If you are not seeing the error, then either
> add a check error command after the save table or use err() to check for
> specific errors such as DUPLICATE or RECORDCHANGED.
> To apply the passive lock you must use a change table command. This will
> apply a passive lock if the record already exists so that it can be updated.
> Note: You must also use change table before using the remove table command.
> Once a passive lock has been created, it must be released before attempting
> to lock another record in the same table, you must either use save table
> (Save), remove table (Delete) or release table (Cancel).
> If you are creating a maintenance window, you must use change table when you
> first display an existing record. If you just use get table, and then use
> change table just before you save, there will be no multi-user handling to
> check that two users have not updated the record at the same time. In this
> situation whoever saves last will win.
> Dexterity's passive locking will allow two users to update the same record
> at the same time as long as they don't update the same field. For example,
> User 1 can change the phone number while user 2 changes payment terms....
> both changes will be saved.
> Hope this helps.
> David Musgrave [MSFT]
> Senior Development Consultant
> MBS Services - Asia Pacific
> Microsoft Business Solutions
> Any views contained within are my personal views and
> not necessarily Microsoft Business Solutions policy.
> This posting is provided "AS IS" with no warranties,
> and confers no rights.
> "Programmer in So Cal" wrote:
> > Hi,
> > just another newbie type of question.... i have a new window with its own
> > table. i'm doing a "copy from window to table" &c, and it works fine to
> > insert data the first time. however, i can tell from the SQL Profiler that
> > when I try to modify the data, it does not do an update--it tries to do
> > another insert (and of course, can't). Is there something I should be
> > setting in Dexterity somewhere to make the table updatable, or do I need to
> > manage this with PassThroughSQL?
> > thanks in advance.