Tableupdate() function

I have a remote view set up to a SQL server database. In the view
definition, I have set up the where clause to indicate SQL fieldonly in the
update criteria. The bufferring is set to Optimistic Record lock (#3). The
table itself has a field ID that is set to autoincrement. If I append a
record and issue the tableupdate() command, I am unable to make any other
changes to that record due to update conflict.

Thus the following code :
..
Append blank
replace fname with "Jim"
=Tableupdate()
replace lname with "marck"
=tableupdate() && <-- this produces a update conflict due to the field ID.

The question is this. Is the only way around this problem to issue a
=Requery() after the first tableupdate(), or is there a better way to do
this.

Any suggestion is appreciated.

Thanks
Shahriar

Stefan
Mon Aug 09 01:11:01 CDT 2004

> The question is this. Is the only way around this problem to issue a
> =Requery() after the first tableupdate(), or is there a better way to do
> this.

The problem may be that the TableUpdate() fails, in the first place.
IOW, you should always check if it returns true or false.
When it returns .F., you can evaluate AERROR() afterwards to
see the server's error message (and then TableRevert() and inform
the user).


hth
-Stefan

"Shahriar" <HelloShahriar@hotmail.com> schrieb im Newsbeitrag
news:uysRc.6729$Se2.222@nwrddc01.gnilink.net...
> I have a remote view set up to a SQL server database. In the view
> definition, I have set up the where clause to indicate SQL fieldonly in the
> update criteria. The bufferring is set to Optimistic Record lock (#3). The
> table itself has a field ID that is set to autoincrement. If I append a
> record and issue the tableupdate() command, I am unable to make any other
> changes to that record due to update conflict.
>
> Thus the following code :
> ..
> Append blank
> replace fname with "Jim"
> =Tableupdate()
> replace lname with "marck"
> =tableupdate() && <-- this produces a update conflict due to the field ID.
>
> The question is this. Is the only way around this problem to issue a
> =Requery() after the first tableupdate(), or is there a better way to do
> this.
>
> Any suggestion is appreciated.
>
> Thanks
> Shahriar
>
>

Shahriar
Mon Aug 09 08:46:54 CDT 2004

Thanks for your reply. I had indicated the reason as to why it fails in the
second tableupdate(). A new ID has been created at the backend and the id
in the view is not updated. As a result one gets an update conflict. My
question was, is Requery() the ONLY technique that can be used?

Shahriar

"Stefan Wuebbe" <stefan.wuebbe@gmx.de> wrote in message
news:2nojbhF2uu5nU2@uni-berlin.de...
> > The question is this. Is the only way around this problem to issue a
> > =Requery() after the first tableupdate(), or is there a better way to do
> > this.
>
> The problem may be that the TableUpdate() fails, in the first place.
> IOW, you should always check if it returns true or false.
> When it returns .F., you can evaluate AERROR() afterwards to
> see the server's error message (and then TableRevert() and inform
> the user).
>
>
> hth
> -Stefan
>
> "Shahriar" <HelloShahriar@hotmail.com> schrieb im Newsbeitrag
> news:uysRc.6729$Se2.222@nwrddc01.gnilink.net...
> > I have a remote view set up to a SQL server database. In the view
> > definition, I have set up the where clause to indicate SQL fieldonly in
the
> > update criteria. The bufferring is set to Optimistic Record lock (#3).
The
> > table itself has a field ID that is set to autoincrement. If I append a
> > record and issue the tableupdate() command, I am unable to make any
other
> > changes to that record due to update conflict.
> >
> > Thus the following code :
> > ..
> > Append blank
> > replace fname with "Jim"
> > =Tableupdate()
> > replace lname with "marck"
> > =tableupdate() && <-- this produces a update conflict due to the field
ID.
> >
> > The question is this. Is the only way around this problem to issue a
> > =Requery() after the first tableupdate(), or is there a better way to do
> > this.
> >
> > Any suggestion is appreciated.
> >
> > Thanks
> > Shahriar
> >
> >
>

Leonid
Mon Aug 09 09:24:06 CDT 2004

Actually REQUERY() is NOT the technique that can be used. After REQUERY()
record pointer may move to the different record and you can't find the
record you updated because you don't know ID. This question was disscussed
several times and here an extract from one of the previous posts which
describes how you can get ID from MSSQL:

if {new record was added} && you can check this using GetFldState()
tableupdate() && update the view record to insert record at SQL Server and
generate new ID value
select 0
=SQLEXEC(CursorGetProp("ConnectHandle","MyView"),"Select @@IDENTITY as
nID","IDCursor")
if used("IDCursor")
select MyView
replace MyIdField with IDCursor.nID
use in IDCursor
tableupdate() && this tableupdate will not generate any additional
command to SQL Server,
&& because MyIdField field that we only changed is not marked as field for
which we send
&& updates to SQL Server. This tableupdate() is required to mark that field
as not changed. It does not dio any other work.
refresh() && refresh view's record. This is needed in case SQL Server
generates also default values for other fields - need to download them to
assure records are in synch.
endif
else
&& just tableupdate()
....
endif


Leonid

"Shahriar" <HelloShahriar@hotmail.com> wrote in message
news:ifLRc.9310$114.5610@nwrddc02.gnilink.net...
> Thanks for your reply. I had indicated the reason as to why it fails in
the
> second tableupdate(). A new ID has been created at the backend and the id
> in the view is not updated. As a result one gets an update conflict. My
> question was, is Requery() the ONLY technique that can be used?
>
> Shahriar
>
> "Stefan Wuebbe" <stefan.wuebbe@gmx.de> wrote in message
> news:2nojbhF2uu5nU2@uni-berlin.de...
> > > The question is this. Is the only way around this problem to issue a
> > > =Requery() after the first tableupdate(), or is there a better way to
do
> > > this.
> >
> > The problem may be that the TableUpdate() fails, in the first place.
> > IOW, you should always check if it returns true or false.
> > When it returns .F., you can evaluate AERROR() afterwards to
> > see the server's error message (and then TableRevert() and inform
> > the user).
> >
> >
> > hth
> > -Stefan
> >
> > "Shahriar" <HelloShahriar@hotmail.com> schrieb im Newsbeitrag
> > news:uysRc.6729$Se2.222@nwrddc01.gnilink.net...
> > > I have a remote view set up to a SQL server database. In the view
> > > definition, I have set up the where clause to indicate SQL fieldonly
in
> the
> > > update criteria. The bufferring is set to Optimistic Record lock
(#3).
> The
> > > table itself has a field ID that is set to autoincrement. If I append
a
> > > record and issue the tableupdate() command, I am unable to make any
> other
> > > changes to that record due to update conflict.
> > >
> > > Thus the following code :
> > > ..
> > > Append blank
> > > replace fname with "Jim"
> > > =Tableupdate()
> > > replace lname with "marck"
> > > =tableupdate() && <-- this produces a update conflict due to the
field
> ID.
> > >
> > > The question is this. Is the only way around this problem to issue a
> > > =Requery() after the first tableupdate(), or is there a better way to
do
> > > this.
> > >
> > > Any suggestion is appreciated.
> > >
> > > Thanks
> > > Shahriar
> > >
> > >
> >
>
>

Stefan
Tue Aug 10 03:48:25 CDT 2004

You're right, I did not read carefully.
In addition to Leonid's comment, see also this quote from an
earlier posting by Remus R about MS SqlServer's options to
handle that issue
>>
IDENT_CURRENT('tablename'): Returns the last identity
value generated for a specified table in any session and any scope.
SCOPE_IDENTITY(): returns the last identity value generated for any table
in the current session and the current scope.
@@IDENTITY returns the last identity value generated for any table in the
current session, across all scopes.
>>

hth
-Stefan

"Shahriar" <HelloShahriar@hotmail.com> schrieb im Newsbeitrag
news:ifLRc.9310$114.5610@nwrddc02.gnilink.net...
> Thanks for your reply. I had indicated the reason as to why it fails in the
> second tableupdate(). A new ID has been created at the backend and the id
> in the view is not updated. As a result one gets an update conflict. My
> question was, is Requery() the ONLY technique that can be used?
>
> Shahriar
>
> "Stefan Wuebbe" <stefan.wuebbe@gmx.de> wrote in message
> news:2nojbhF2uu5nU2@uni-berlin.de...
> > > The question is this. Is the only way around this problem to issue a
> > > =Requery() after the first tableupdate(), or is there a better way to do
> > > this.
> >
> > The problem may be that the TableUpdate() fails, in the first place.
> > IOW, you should always check if it returns true or false.
> > When it returns .F., you can evaluate AERROR() afterwards to
> > see the server's error message (and then TableRevert() and inform
> > the user).
> >
> >
> > hth
> > -Stefan
> >
> > "Shahriar" <HelloShahriar@hotmail.com> schrieb im Newsbeitrag
> > news:uysRc.6729$Se2.222@nwrddc01.gnilink.net...
> > > I have a remote view set up to a SQL server database. In the view
> > > definition, I have set up the where clause to indicate SQL fieldonly in
> the
> > > update criteria. The bufferring is set to Optimistic Record lock (#3).
> The
> > > table itself has a field ID that is set to autoincrement. If I append a
> > > record and issue the tableupdate() command, I am unable to make any
> other
> > > changes to that record due to update conflict.
> > >
> > > Thus the following code :
> > > ..
> > > Append blank
> > > replace fname with "Jim"
> > > =Tableupdate()
> > > replace lname with "marck"
> > > =tableupdate() && <-- this produces a update conflict due to the field
> ID.
> > >
> > > The question is this. Is the only way around this problem to issue a
> > > =Requery() after the first tableupdate(), or is there a better way to do
> > > this.
> > >
> > > Any suggestion is appreciated.
> > >
> > > Thanks
> > > Shahriar
> > >
> > >
> >
>
>

Shahriar
Tue Aug 10 08:34:11 CDT 2004

what would be wrong with the following code?

append blank
=Tableupdate()
=Requery()
goto bottom
&& since I have an autoincrement field defined, would I not be always
pointing to the right record ? Thus I dont have to worry about what ID value
SQL server has assigned.

Shahriar




"Leonid" <leonid@NOgradaSPAM.lv> wrote in message
news:%233sYIyhfEHA.2764@TK2MSFTNGP11.phx.gbl...
> Actually REQUERY() is NOT the technique that can be used. After REQUERY()
> record pointer may move to the different record and you can't find the
> record you updated because you don't know ID. This question was disscussed
> several times and here an extract from one of the previous posts which
> describes how you can get ID from MSSQL:
>
> if {new record was added} && you can check this using GetFldState()
> tableupdate() && update the view record to insert record at SQL Server
and
> generate new ID value
> select 0
> =SQLEXEC(CursorGetProp("ConnectHandle","MyView"),"Select @@IDENTITY as
> nID","IDCursor")
> if used("IDCursor")
> select MyView
> replace MyIdField with IDCursor.nID
> use in IDCursor
> tableupdate() && this tableupdate will not generate any additional
> command to SQL Server,
> && because MyIdField field that we only changed is not marked as field for
> which we send
> && updates to SQL Server. This tableupdate() is required to mark that
field
> as not changed. It does not dio any other work.
> refresh() && refresh view's record. This is needed in case SQL Server
> generates also default values for other fields - need to download them to
> assure records are in synch.
> endif
> else
> && just tableupdate()
> ....
> endif
>
>
> Leonid
>
> "Shahriar" <HelloShahriar@hotmail.com> wrote in message
> news:ifLRc.9310$114.5610@nwrddc02.gnilink.net...
> > Thanks for your reply. I had indicated the reason as to why it fails in
> the
> > second tableupdate(). A new ID has been created at the backend and the
id
> > in the view is not updated. As a result one gets an update conflict.
My
> > question was, is Requery() the ONLY technique that can be used?
> >
> > Shahriar
> >
> > "Stefan Wuebbe" <stefan.wuebbe@gmx.de> wrote in message
> > news:2nojbhF2uu5nU2@uni-berlin.de...
> > > > The question is this. Is the only way around this problem to issue
a
> > > > =Requery() after the first tableupdate(), or is there a better way
to
> do
> > > > this.
> > >
> > > The problem may be that the TableUpdate() fails, in the first place.
> > > IOW, you should always check if it returns true or false.
> > > When it returns .F., you can evaluate AERROR() afterwards to
> > > see the server's error message (and then TableRevert() and inform
> > > the user).
> > >
> > >
> > > hth
> > > -Stefan
> > >
> > > "Shahriar" <HelloShahriar@hotmail.com> schrieb im Newsbeitrag
> > > news:uysRc.6729$Se2.222@nwrddc01.gnilink.net...
> > > > I have a remote view set up to a SQL server database. In the view
> > > > definition, I have set up the where clause to indicate SQL fieldonly
> in
> > the
> > > > update criteria. The bufferring is set to Optimistic Record lock
> (#3).
> > The
> > > > table itself has a field ID that is set to autoincrement. If I
append
> a
> > > > record and issue the tableupdate() command, I am unable to make any
> > other
> > > > changes to that record due to update conflict.
> > > >
> > > > Thus the following code :
> > > > ..
> > > > Append blank
> > > > replace fname with "Jim"
> > > > =Tableupdate()
> > > > replace lname with "marck"
> > > > =tableupdate() && <-- this produces a update conflict due to the
> field
> > ID.
> > > >
> > > > The question is this. Is the only way around this problem to issue
a
> > > > =Requery() after the first tableupdate(), or is there a better way
to
> do
> > > > this.
> > > >
> > > > Any suggestion is appreciated.
> > > >
> > > > Thanks
> > > > Shahriar
> > > >
> > > >
> > >
> >
> >
>
>

Leonid
Tue Aug 10 08:54:58 CDT 2004

It's true only if you have ORDER BY your autoincrement field and don't have
WHERE clause. Also this may not work correctly in multiuser environment.

Leonid

"Shahriar" <HelloShahriar@hotmail.com> wrote in message
news:n94Sc.23640$114.13902@nwrddc02.gnilink.net...
> what would be wrong with the following code?
>
> append blank
> =Tableupdate()
> =Requery()
> goto bottom
> && since I have an autoincrement field defined, would I not be always
> pointing to the right record ? Thus I dont have to worry about what ID
value
> SQL server has assigned.
>
> Shahriar
>
>
>
>
> "Leonid" <leonid@NOgradaSPAM.lv> wrote in message
> news:%233sYIyhfEHA.2764@TK2MSFTNGP11.phx.gbl...
> > Actually REQUERY() is NOT the technique that can be used. After
REQUERY()
> > record pointer may move to the different record and you can't find the
> > record you updated because you don't know ID. This question was
disscussed
> > several times and here an extract from one of the previous posts which
> > describes how you can get ID from MSSQL:
> >
> > if {new record was added} && you can check this using GetFldState()
> > tableupdate() && update the view record to insert record at SQL Server
> and
> > generate new ID value
> > select 0
> > =SQLEXEC(CursorGetProp("ConnectHandle","MyView"),"Select @@IDENTITY as
> > nID","IDCursor")
> > if used("IDCursor")
> > select MyView
> > replace MyIdField with IDCursor.nID
> > use in IDCursor
> > tableupdate() && this tableupdate will not generate any additional
> > command to SQL Server,
> > && because MyIdField field that we only changed is not marked as field
for
> > which we send
> > && updates to SQL Server. This tableupdate() is required to mark that
> field
> > as not changed. It does not dio any other work.
> > refresh() && refresh view's record. This is needed in case SQL Server
> > generates also default values for other fields - need to download them
to
> > assure records are in synch.
> > endif
> > else
> > && just tableupdate()
> > ....
> > endif
> >
> >
> > Leonid
> >
> > "Shahriar" <HelloShahriar@hotmail.com> wrote in message
> > news:ifLRc.9310$114.5610@nwrddc02.gnilink.net...
> > > Thanks for your reply. I had indicated the reason as to why it fails
in
> > the
> > > second tableupdate(). A new ID has been created at the backend and
the
> id
> > > in the view is not updated. As a result one gets an update conflict.
> My
> > > question was, is Requery() the ONLY technique that can be used?
> > >
> > > Shahriar
> > >
> > > "Stefan Wuebbe" <stefan.wuebbe@gmx.de> wrote in message
> > > news:2nojbhF2uu5nU2@uni-berlin.de...
> > > > > The question is this. Is the only way around this problem to
issue
> a
> > > > > =Requery() after the first tableupdate(), or is there a better way
> to
> > do
> > > > > this.
> > > >
> > > > The problem may be that the TableUpdate() fails, in the first place.
> > > > IOW, you should always check if it returns true or false.
> > > > When it returns .F., you can evaluate AERROR() afterwards to
> > > > see the server's error message (and then TableRevert() and inform
> > > > the user).
> > > >
> > > >
> > > > hth
> > > > -Stefan
> > > >
> > > > "Shahriar" <HelloShahriar@hotmail.com> schrieb im Newsbeitrag
> > > > news:uysRc.6729$Se2.222@nwrddc01.gnilink.net...
> > > > > I have a remote view set up to a SQL server database. In the view
> > > > > definition, I have set up the where clause to indicate SQL
fieldonly
> > in
> > > the
> > > > > update criteria. The bufferring is set to Optimistic Record lock
> > (#3).
> > > The
> > > > > table itself has a field ID that is set to autoincrement. If I
> append
> > a
> > > > > record and issue the tableupdate() command, I am unable to make
any
> > > other
> > > > > changes to that record due to update conflict.
> > > > >
> > > > > Thus the following code :
> > > > > ..
> > > > > Append blank
> > > > > replace fname with "Jim"
> > > > > =Tableupdate()
> > > > > replace lname with "marck"
> > > > > =tableupdate() && <-- this produces a update conflict due to the
> > field
> > > ID.
> > > > >
> > > > > The question is this. Is the only way around this problem to
issue
> a
> > > > > =Requery() after the first tableupdate(), or is there a better way
> to
> > do
> > > > > this.
> > > > >
> > > > > Any suggestion is appreciated.
> > > > >
> > > > > Thanks
> > > > > Shahriar
> > > > >
> > > > >
> > > >
> > >
> > >
> >
> >
>
>

budieko
Fri Aug 13 00:07:06 CDT 2004

Hi Leonid,
What about this statement in VFP onlinehelp:

Tip Calling the REFRESH( ) function can result in a significant impact on
performance, because the function reexecutes the query on which the view is
based. Therefore, do not call this function more than necessary

thanks

"Leonid" <leonid@NOgradaSPAM.lv> wrote in message
news:#3sYIyhfEHA.2764@TK2MSFTNGP11.phx.gbl...
> Actually REQUERY() is NOT the technique that can be used. After REQUERY()
> record pointer may move to the different record and you can't find the
> record you updated because you don't know ID. This question was disscussed
> several times and here an extract from one of the previous posts which
> describes how you can get ID from MSSQL:
>
> if {new record was added} && you can check this using GetFldState()
> tableupdate() && update the view record to insert record at SQL Server
and
> generate new ID value
> select 0
> =SQLEXEC(CursorGetProp("ConnectHandle","MyView"),"Select @@IDENTITY as
> nID","IDCursor")
> if used("IDCursor")
> select MyView
> replace MyIdField with IDCursor.nID
> use in IDCursor
> tableupdate() && this tableupdate will not generate any additional
> command to SQL Server,
> && because MyIdField field that we only changed is not marked as field for
> which we send
> && updates to SQL Server. This tableupdate() is required to mark that
field
> as not changed. It does not dio any other work.
> refresh() && refresh view's record. This is needed in case SQL Server
> generates also default values for other fields - need to download them to
> assure records are in synch.
> endif
> else
> && just tableupdate()
> ....
> endif
>
>
> Leonid
>
> "Shahriar" <HelloShahriar@hotmail.com> wrote in message
> news:ifLRc.9310$114.5610@nwrddc02.gnilink.net...
> > Thanks for your reply. I had indicated the reason as to why it fails in
> the
> > second tableupdate(). A new ID has been created at the backend and the
id
> > in the view is not updated. As a result one gets an update conflict.
My
> > question was, is Requery() the ONLY technique that can be used?
> >
> > Shahriar
> >
> > "Stefan Wuebbe" <stefan.wuebbe@gmx.de> wrote in message
> > news:2nojbhF2uu5nU2@uni-berlin.de...
> > > > The question is this. Is the only way around this problem to issue
a
> > > > =Requery() after the first tableupdate(), or is there a better way
to
> do
> > > > this.
> > >
> > > The problem may be that the TableUpdate() fails, in the first place.
> > > IOW, you should always check if it returns true or false.
> > > When it returns .F., you can evaluate AERROR() afterwards to
> > > see the server's error message (and then TableRevert() and inform
> > > the user).
> > >
> > >
> > > hth
> > > -Stefan
> > >
> > > "Shahriar" <HelloShahriar@hotmail.com> schrieb im Newsbeitrag
> > > news:uysRc.6729$Se2.222@nwrddc01.gnilink.net...
> > > > I have a remote view set up to a SQL server database. In the view
> > > > definition, I have set up the where clause to indicate SQL fieldonly
> in
> > the
> > > > update criteria. The bufferring is set to Optimistic Record lock
> (#3).
> > The
> > > > table itself has a field ID that is set to autoincrement. If I
append
> a
> > > > record and issue the tableupdate() command, I am unable to make any
> > other
> > > > changes to that record due to update conflict.
> > > >
> > > > Thus the following code :
> > > > ..
> > > > Append blank
> > > > replace fname with "Jim"
> > > > =Tableupdate()
> > > > replace lname with "marck"
> > > > =tableupdate() && <-- this produces a update conflict due to the
> field
> > ID.
> > > >
> > > > The question is this. Is the only way around this problem to issue
a
> > > > =Requery() after the first tableupdate(), or is there a better way
to
> do
> > > > this.
> > > >
> > > > Any suggestion is appreciated.
> > > >
> > > > Thanks
> > > > Shahriar
> > > >
> > > >
> > >
> >
> >
>
>

Stefan
Fri Aug 13 04:20:46 CDT 2004

Refresh() is able to requery one or a few lines only - as opposed
to Requery() which fetches the entire "Select .. Where ..."
So the tip is still valid in saying "do not call this function more than
necessary" - but if it _is necessary, Refresh() can be a good option.


-Stefan

"budieko" <eko_dja@myrealboxJUSTREMOVE.com> schrieb im Newsbeitrag
news:%23Ui5WHPgEHA.2524@TK2MSFTNGP09.phx.gbl...
> Hi Leonid,
> What about this statement in VFP onlinehelp:
>
> Tip Calling the REFRESH( ) function can result in a significant impact on
> performance, because the function reexecutes the query on which the view is
> based. Therefore, do not call this function more than necessary
>
> thanks
>
> "Leonid" <leonid@NOgradaSPAM.lv> wrote in message
> news:#3sYIyhfEHA.2764@TK2MSFTNGP11.phx.gbl...
>> Actually REQUERY() is NOT the technique that can be used. After REQUERY()
>> record pointer may move to the different record and you can't find the
>> record you updated because you don't know ID. This question was disscussed
>> several times and here an extract from one of the previous posts which
>> describes how you can get ID from MSSQL:
>>
>> if {new record was added} && you can check this using GetFldState()
>> tableupdate() && update the view record to insert record at SQL Server
> and
>> generate new ID value
>> select 0
>> =SQLEXEC(CursorGetProp("ConnectHandle","MyView"),"Select @@IDENTITY as
>> nID","IDCursor")
>> if used("IDCursor")
>> select MyView
>> replace MyIdField with IDCursor.nID
>> use in IDCursor
>> tableupdate() && this tableupdate will not generate any additional
>> command to SQL Server,
>> && because MyIdField field that we only changed is not marked as field for
>> which we send
>> && updates to SQL Server. This tableupdate() is required to mark that
> field
>> as not changed. It does not dio any other work.
>> refresh() && refresh view's record. This is needed in case SQL Server
>> generates also default values for other fields - need to download them to
>> assure records are in synch.
>> endif
>> else
>> && just tableupdate()
>> ....
>> endif
>>
>>
>> Leonid
>>
>> "Shahriar" <HelloShahriar@hotmail.com> wrote in message
>> news:ifLRc.9310$114.5610@nwrddc02.gnilink.net...
>> > Thanks for your reply. I had indicated the reason as to why it fails in
>> the
>> > second tableupdate(). A new ID has been created at the backend and the
> id
>> > in the view is not updated. As a result one gets an update conflict.
> My
>> > question was, is Requery() the ONLY technique that can be used?
>> >
>> > Shahriar
>> >
>> > "Stefan Wuebbe" <stefan.wuebbe@gmx.de> wrote in message
>> > news:2nojbhF2uu5nU2@uni-berlin.de...
>> > > > The question is this. Is the only way around this problem to issue
> a
>> > > > =Requery() after the first tableupdate(), or is there a better way
> to
>> do
>> > > > this.
>> > >
>> > > The problem may be that the TableUpdate() fails, in the first place.
>> > > IOW, you should always check if it returns true or false.
>> > > When it returns .F., you can evaluate AERROR() afterwards to
>> > > see the server's error message (and then TableRevert() and inform
>> > > the user).
>> > >
>> > >
>> > > hth
>> > > -Stefan
>> > >
>> > > "Shahriar" <HelloShahriar@hotmail.com> schrieb im Newsbeitrag
>> > > news:uysRc.6729$Se2.222@nwrddc01.gnilink.net...
>> > > > I have a remote view set up to a SQL server database. In the view
>> > > > definition, I have set up the where clause to indicate SQL fieldonly
>> in
>> > the
>> > > > update criteria. The bufferring is set to Optimistic Record lock
>> (#3).
>> > The
>> > > > table itself has a field ID that is set to autoincrement. If I
> append
>> a
>> > > > record and issue the tableupdate() command, I am unable to make any
>> > other
>> > > > changes to that record due to update conflict.
>> > > >
>> > > > Thus the following code :
>> > > > ..
>> > > > Append blank
>> > > > replace fname with "Jim"
>> > > > =Tableupdate()
>> > > > replace lname with "marck"
>> > > > =tableupdate() && <-- this produces a update conflict due to the
>> field
>> > ID.
>> > > >
>> > > > The question is this. Is the only way around this problem to issue
> a
>> > > > =Requery() after the first tableupdate(), or is there a better way
> to
>> do
>> > > > this.
>> > > >
>> > > > Any suggestion is appreciated.
>> > > >
>> > > > Thanks
>> > > > Shahriar
>> > > >
>> > > >
>> > >
>> >
>> >
>>
>>
>
>