Is there's a way to post only the changed fields of a dataset rather than all the fields in a request?

I'm using auto commit on a grid bound dataset. A couple fields are longer text comment fields that don't change there. I'd like not to have to send them each time other fields change. Is that possible?

I beleive EWB 2 did that - but in EWB 3 it seems everything get's sent back on Commit from what I have seen.  I would prefer less traffic too.

Walter

Bummer. Maybe there's a way to hook into the request with an event and make changes manually. I'm using a Go backend so I have complete control over the processing and response side. If I could get to the JSON on the client before it's sent I could pull those fields manually.

If I don't get any further responses I'll send a direct support request. Maybe there's something still buried in the code.

Thanks,
GCR

Walter Matte wrote:

I believe EWB 2 did that - but in EWB 3 it seems everything get's sent back on Commit from what I have seen.  I would prefer less traffic too.

Walter

<< Is there's a way to post only the changed fields of a dataset rather than all the fields in a request?

I'm using auto commit on a grid bound dataset. A couple fields are longer text comment fields that don't change there. I'd like not to have to send them each time other fields change. Is that possible? >>

This was changed in order to accommodate the new database/dataset architecture that uses parameterized SQL to execute inserts, updates, and deletes.  All columns have to be passed so that all of the parameters can be filled in properly.  Without this, non-modified columns could (depends upon the defined SQL) accidentally be set to NULLs.  And, IFNULL-type processing on the parameters doesn't work if I want to allow the front end to insert, or update row columns with actual NULL values, which must be allowed for proper behavior.

EWB 2.x had auto-generated SQL, but it had issues with:

- Syntax compatibility between back-end database servers/engines (especially with auto-generated columns and retrieving the generated column values)

- Updates where the updates may be going to multiple tables due to the fact that the dataset row selection originated from a query with joins, etc.

Unfortunately, there's not much that I can do about massaging the SQL for dataset commands when that SQL can literally be anything supported by the back-end.  ADO, for example, allows for multiple statements in a dataset command's SQL for identity column value retrieval after inserts with SQL Server.

I'll do some more thinking, but this may require something that just requires re-imagining the dataset commands as something more flexible, like EWB Object Pascal code that can perform the commands instead.

Tim Young
Elevate Software
www.elevatesoft.com