We've used DbLinq in a project with oracle, dbmetal to generate the code and the only had these problems:
1 - An using error in the generated classes 2- Composite Keys not supported 3 - Transactions not support (we just used a common context carefully...) For the rest DbLinq worked very well. Thanks. On May 8, 1:40 pm, Pascal Craponne <[email protected]> wrote: > Hi, > I'm not sure I understand: DbLinq is not an entity framework, it's the "linq > to sql" for other databases. > Apparently there is a but with string analysis (regarding you "OBJECT#"). It > can be avoided by using /culture=IVL to DbMetal command line switches, but > I'm not sure the generated class will have a valid name anyway. > > Pascal. > > On Thu, May 7, 2009 at 22:56, JA <[email protected]> wrote: > > > so if i paid attention to the fact that in dblinq the goal is to > > develop linq to oracle (i.e linq to sql for Oracle) and not a EF > > provider i probably wouldnt need to ask this question. > > > so i used the /dbml on dbmetal to output a dbml file then dropped it > > into a vs project and this gets me into familiar grounds/context - > > even though im after a EF provider for Oracle. > > > thanks --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
