>>SELECT ThisTable
>>REPLACE OtherTable.SomeField WITH Something
>>
>>fails if ThisTable is at EOF. Adding IN is the fix, not the problem.
>
>Then it was this way around. The solution is SQL UPDATE rather then REPLACE anyway. :)
>
>>>Anyway. No, one must not. If the code runs encapsulated (in a distinct DE) nothing will change work area. This happens only to code running in a form or DE bound to a form. What violates n-tier approach. One of the reasons to encapsulate data processing from FORM. (And FORMS DE in particular)
>>
>>I got religion on this one working on an application that used timers. Yes, if the code called by the timer was perfect, then it wasn't an issue, but I don't want to rely on every bit of code being perfect. (FWIW, that's all the application that got me religion on declaring every variable LOCAL.)
>>
>>Tamar
>
>What I mean is, move the code out of the place where the timer interferes. Just create an additional private session, call with some parameters and let it do the work. Whatever the timer on the form is doing - it will not change the session. Same is true for any OCX / grid / whatever that plays with workarea / record pointer in forms datasession. This is the idea of an encapsulated business object, isn't it?

If the timer is inside a private data session form, when it goes off, won't it switch to the other data session?

What I wish SQL Insert permitted the same structure as replace

replace
this with that, ;
this1 with that1

is better than
insert into table ;
this, ;
this1;
values
that,;
that1

especially as the length of the command increates.