I have a question about the SQLPreview Event of DataWindow
When you want to skip your current query based on a specific condition, for example, if I want to skip a DELETE query from being sent to the database, I can return 2 from this event, and it will skip the current query pass entirely, and will move on to the next query (whatever records are waiting to get UPDATED or DELETED or INSERTED)
When we use a return 2, at the end of the SQLPreview event, maybe because we decide to skip the current operation, the DataWindow removes the record from the DELETE buffer for a Delete statement ( I believe it would set the status of the row to NotModified for that row in the Primary buffer in case we skip an INSERT operation, I haven't tested this, but it's just a guess)
I have written some code to take a backup of this record in a datastore (which rather looks ugly :-) ), and use it later and this code works (although what I might do later with this copied row is TBD)
Is there a way I can instruct PowerBuilder to keep the row while I also decide to skip the current query? I think NOT. This indeed looks like a weird scenario. I can alternately return 1 but that will stop subsequent updates/deletes/inserts from happening
Any suggestion helps!
Thanks,
Krishna
Initially, I had used DataStores to keep track of these rows but due to some reason that eludes my rusty brain, the SME is very particular not to use anything external to the DataWindow. I have tried so many different approaches, and explained the problems with all of these, but to no avail. All of it boils down to the fact that we are all at the mercy of the DataWindow and I respect and applaud that. I usually refrain from playing with Item Statuses and intricate events like SQLPreview because I want to just let PB do its job using its already robust mechanism. If I keep touching these, the DW will feel like what I would feel if someone keeps poking their nose into my work and telling me how to do it instead of what they want. PB is going to hate me for this :-)
If there is ANY chance that someone else will be maintaining or enhancing this application in the future or if you will need to revisit it after this work is completed, then it would be in everybody's interest for you to carefully and completely document this code... including not only WHAT the code does, but WHY - largely because this will be very non-typical use of the DataWindow. IMHO, your SME is taking a large risk by insisting on you coding such non-standard behavior. Good luck!