I agree. I would hate for the information to not be presented to those of us who would really benefit from it. Thanks for your contributions Walter. I know from reading the messages they took time and consideration before posting.



>Hi Tracy,
>
>I was not asking you to do anything... I just used your message to reply to kevins post.
>
>I agree I think those messages were important as there is a lot to learn from. I'm not sure what to do next. Kevin and I are currently emailing directly to see how we can continue sharing the knowledge.
>
>I do not feel I've got the time to write for magazines, but I feel this is something that very well could fit into the re-established VFP magazines. There is a lot of assumptions made and accepted as common wisdom that really need to be fleshed out.
>
>
>
>Walter,
>
>
>>I'm more than willing to do that, however, I'm not sure I could post Kevin's reply back. Would Michel consider that circumventing the system somehow? Michel? Can you respond? (I'll probably have to ask in the UT questions section). I don't want to break any rules intentionally. I'm afraid we all may have to suffer without the knowledge of this go around on databases. Shame... it was very enlightening and I think a lot of us were benefitting.
>>
>>
>>
>>>Tracy,
>>>
>>>Since, kevin has been banned, and I'm not able to reply to him directly anymore. I'll do it to you and will copy kevin in a private email.
>>>
>>>
>>>Kevin,
>>>
>>>>>Next question - suppose you want to get immediate feedback on what was changed on a database row. An UPDATE occurs, and you want a snapshot of the row before the UPDATE occured, and then after the UPDATE occured. (including any calculated columns, or columns affected by a trigger, etc.)
>>>
>>>I'm not sure what kind of situation you are refering to. Are you talking about an explicit change to the invoice or an implicit change or both?
>>>
>>>If it is about an explicit change (So the front end explicitely wants to change anything to the invoice) and you want to return the before change and afterchange information I'd do something like:
>>>
>>>

SELECT * FROM invoiceheader WHERE invoiceno = @nInvoiceno
>>>SELECT * FROM invoicedetails WHERE invoiceno = @nInvoiceno
>>>
>>>-- Body that has any required SQL statement in there to update either invoiceheader or invoicedetails
>>>
>>>UPDATE invoiceheader SET .... = ..... WHERE invoiceno = @invoiceno
>>>UPDATE invoicedetails SET .... = ..... WHERE invoiceno = @invoiceno
>>>
>>>SELECT * FROM invoiceheader WHERE invoiceno = @nInvoiceno
>>>SELECT * FROM invoicedetails WHERE invoiceno = @nInvoiceno

>>>
>>>Addtitionally I could wrap everything into a transaction for taking care of all concurrent update conflicts. This could well be done in a single SPT batch.
>>>
>>>If you are talking about implicit updates, so an update is caused by any other SQL statement, there is no mechanism to send back the information to the client (an UPDATE with SQLExec() does not return any resultsets. You could think of storing that info into a log table, so you could retrieve that info at will. You can use triggers to fill that log with the info from any update.
>>>
>>>Again, I'm not sure what you would need it for. IOW, what problem are you trying to solve?
>>>
>>>Walter,