Hi,
I don't know much about DBLink, but talking about FB, Why don't you
simply just use Firebird 2.1 insert syntax ?
INSERT INTO … VALUES (…) [RETURNING [INTO ]]
Example:
1. INSERT INTO T1 (F1, F2)
VALUES (:F1, :F2)
RETURNING F1 INTO :PK
Which allows to insert the values, and after the insertion retrieve
the value of the desired field
Best regards,
Mocte
On 30 sep, 18:59, "Pascal Craponne" <[EMAIL PROTECTED]> wrote:
> I just committed a new version of DataContext where all lists (insert,
> update and delete) are handled in a unified entity tracker. Tests show that
> apparently things still work, but this is not a 100% certainty. Please let
> me know if you find some regressions that slipped through the net.
> Regarding our point 2: all requests (insert, delete) are handled in correct
> order.
>
>
>
> On Mon, Sep 29, 2008 at 22:20, Pascal Craponne <[EMAIL PROTECTED]> wrote:
> > The point 2 was supposed to be a small change.I said to myself that I
> > would be kind to make the change. Call me Mr Nice Guy... :)
>
> > Well...
>
> > There are a LOT of changes required:
> > 1. All control needs to go back to DataContext (I noticed this problem a
> > long time ago, with the IManagedTable interface, whose purpose was just a
> > workaround).
> > 2. The right way to process entities, it NOT AT ALL to process all INSERTs,
> > then, UPDATEs, then DELETEs successfully.
> > No, all registered entites must be processed as a single list (this will be
> > fun), as they come.
> > 3. Since entities are in a single list, they can also be "ignored": for
> > example, adding an entity for insert, then registering it for delete will
> > just mark it as "to be ignored" in list...
>
> > So, this is a bit more tricky than I expected to get things done correctly.
> > But necessary anyway.
>
> > Be patient!
>
> > On Mon, Sep 29, 2008 at 15:12, Julio César Carrascal Urquijo <
> > [EMAIL PROTECTED]> wrote:
>
> >> Hi Pascal
>
> >> On Sep 28, 4:36 pm, "Pascal Craponne" <[EMAIL PROTECTED]> wrote:
> >> > 1. This is an important point, and I don't like much the idea of giving
> >> > control to the vendor (it would give to much responsibility on the
> >> > vendor).Ideally,
> >> > the Upsert would be able to support the following variants:
> >> > - Single query insert
> >> > - Double query insert, generated columns values being loaded after the
> >> > insert statement (Ingres requirements)
> >> > - Double query insert, generated columns values being loaded before the
> >> > insert statement (Firebird)
> >> > So maybe we could find a compromise like:
> >> > - vendor declares its requirements (one in the three above, or something
> >> > more extensible)
> >> > - core executes queries, depending on the vendor's requirements.
>
> >> > This needs to be refined, before implementation, and I'd like to get
> >> other
> >> > contributors' opinion.
>
> >> That would work, for Firebird at least. Thanks
>
> >> > 2. Yes, I understand, and this could be easily done. Anyway, we must
> >> keep in
> >> > mind that this is just a workaround, until DbLinq fully manages entity
> >> sets.
>
> >> I understand. But I want to stress that this is a blocker for most
> >> uses of DbLinq. A simple CRUD application would require specific
> >> ordering of statements if the database has foreing keys.
>
> >> Cheers.
>
> > --
> > Pascal.
>
> > jabber/gtalk: [EMAIL PROTECTED]
> > msn: [EMAIL PROTECTED]
>
> --
> Pascal.
>
> jabber/gtalk: [EMAIL PROTECTED]
> msn: [EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"DbLinq" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/dblinq?hl=en
-~----------~----~----~----~------~----~------~--~---
