dotConnect Oracle 5.55beta wrestles with INSERT

[PangoChris]

The new version of dotConnect for Oracle has introduced a LINQ to SQL bug in which calling SubmitChanges() to insert multiple rows into the same table crashes.

I don't have time to isolate and produce sample code, but dbMonitor tells the story and reverting to the previous version fixes the issue.

The table being inserted into has a standard primary key that gets autogenerated off of a number sequence. The correct properties have been set for the table in the LINQ to SQL model, as it worked prior to the latest dotConnect version. When SubmitChanges() is called with more than one new record to be inserted into the table, according to dbMonitor, the *first* INSERT works as expected:

INSERT INTO table (field1, field2) VALUES(:p1, :p2) RETURNING primaryKey INTO :ret1

The database correctly returns into :ret1, say 100.

The *second* INSERT bombs, as it unwisely tries to reuse the return value from the *first* INSERT as the primary key for the second record. Yikes. So this happens:

INSERT INTO table (field1, field2, primaryKey) VALUES(:p1, :p2, :p3) RETURNING primaryKey INTO :ret1

and dotConnect is setting :p3 to 100, so Oracle explodes because obviously that conflicts with the record we just tried to insert a second ago.

Hope that's enough info to reproduce. I was unable to persuade my client that their database already has all the rows they'll ever need.

[AndreyR]

Thank you for the report, we are investigating the situation.

[AndreyR]

We have fixed the problem. The fix will be available in the nearest build.