Hi Julio César, that's good news anyway :) The vendor model was designed to be easily extensible, and apparently we succeeded. Regarding your questions: 1. Initially, all queries were working in a single statement, but we had to change this behavior to double statement for Ingres. I still fear that we have problems on some vendors where executing two requests may be different that executing a double one. So it is planned to support single and double requests. Can you make the insert statements fit in one single request? 2. Dependencies are not supported yet, so this there's probably nothing to do now (except implementing cascading in DbLinq core).
Let me know if you want to be added to project's contributors, so you can commit firebird support by yourself. Just one question: does you implementation support schema extraction (so it can work with DbMetal)? Pascal. On Sun, Sep 28, 2008 at 05:38, Julio César Carrascal Urquijo < [EMAIL PROTECTED]> wrote: > > Hi. > > I'm working on Firebird SQL (http://www.firebird.org/) support for > DbLinq. I have to thank you all for making so easy to support new > databases. After only a couple of hours I had basic querying > capabilities working and most of the time after that was porting the > Northwind SQL scripts. > > Right now, almost all of the sample mysql queries are working but I've > hit some problems. Maybe some one in the group can help me: > > 1) Requesting generated IDs. > Currently inserting a new row with an auto_increment column executes > an INSERT statement and then fetches the generated ID. > > In Firebird there's no such thing as an auto_increment column but it > can be simulated with a sequence and a trigger (That's what I have now > in the SQL scripts). But using this method I couldn't reliably obtain > the generated ID from the trigger. > > The recommended way to do this in Firebird is to generate the ID first > and execute the INSERT with that value but I haven't found a way to > override this behavior in SqlProvider. There's a GetInsertIds() method > but I'll need to execute it before executing the INSERT. > > 2) Specifying order of deletes. > The last example in DbLinq.MySql.Example retrieves the first Order and > tries to delete it: > > db.Orders.DeleteOnSubmit(db.Orders.First()); > db.SubmitChanges(); > > But Firebird correctly warns that there are "Order Details" rows > referencing the Order. I modified the example to retrieve the > OrderDetails of the order and remove them first: > > var order = db.Orders.First(); > foreach (var od in order.OrderDetails) > db.OrderDetails.DeleteOnSubmit(od); > db.Orders.DeleteOnSubmit(order); > db.SubmitChanges(); > > But the Order was still deleted first. I found out that the order in > which those deletes are issued is dependent on a _tableMap dictionary > in the DataContext class and tables get added as they're used for the > first time. So for the time been, I've added a dummy query at the top > of the program to load OrderDetails first. > > I still think there should be a more predictable way to change the > order in which statements are executed. Do you know such a way? > > Thanks > > > -- 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 -~----------~----~----~----~------~----~------~--~---
