I kind of did it. Now if Dataset has parameter "InsertReturningFields", the INSERT SQL will contain RETURNING part. Processing implemented for Firebird.
Full commit message:
* Support of INSERT...RETURNING construction
* New Dataset option "InsertReturningFields" that has to have value of ","-separated list of fields that will be assigned after Post (f.ex. "ID,Master_ID,Something"). This value will be added to INSERT statement as is.
+ TZGenericCachedResolver.FormInsertStatement, processes option "InsertReturningFields"
+ TZInterbase6CachedResolver, assigns values after Posting the INSERT statement
+ TZInterbase6PreparedStatement.ExecuteUpdatePrepared, creates result set for INSERT...RETURNING queries and returns it in LastResultSet property
* GetAffectedRows, redesigned to process the buffer correctly; returns results for stExecProc StatementType
The modified files are in attachment. I tried to keep number of changes as low as possible.
How to test:
Code: Select all
CREATE OR ALTER TRIGGER TRG_SOMETABLE_BI0 FOR SOMETABLE
ACTIVE BEFORE INSERT POSITION 0
IF (NEW.Id IS NULL OR NEW.Id = 0) THEN
NEW.Id = NEXT VALUE FOR Insertgen_SOMETABLE;
2. App: Grid, Dataset linked to SOMETABLE; add "InsertReturningFields=ID" to Dataset's Parameters
3. Runtime: insert a record, fill required fields EXCEPT ID, post changes. You'll see ID field filled with freshly generated value.Questions
safe? This was the most compact way as I didn't like an idea of messing with cases and data types.
2. What about TZInterbase6CallableStatement.ExecuteUpdatePrepared? The method does something different than TZInterbase6PreparedStatement.ExecuteUpdatePrepared does. I'm not quite sure what this branch of classes for and whether this class could be used for executing an INSERT.
You do not have the required permissions to view the files attached to this post.