Today, I can find only one way to identify a database given a single connection string: testing it using different drivers. And this sucks. We could implement a less-sucking method, with a two steps process: 1. for each vendor, say if yes or no it could handle the given connection string as a valid one 2. for all vendors who answered yes, test them, by trying to connect them.
And this leads to the second problem, which is creating a an IDbConnection from a given string, this IDbConnection being compatible with the tested vendor. Maybe another approach would be to "brute force test" all drivers (IDbConnection) present in current AppDomain, and once found the correct one, find the Vendor that could handle it. This second approach would also solve the case where we only give the IDbConnection instance. Anyway, I don't really like those solutions. This is a dirty hack. A better idea, someone? On Mon, Oct 6, 2008 at 19:42, Atsushi Eno <[EMAIL PROTECTED]> wrote: > > Hi, > > To my understanding, an essential problem with related to this > fileOrServerOrConnection is that it could be either a filename, > server name or a connection string. Hence, this string is not > always valid connectionString for SqlConnection. > And not all database engines support constructing database > connection by a filename (even SQL Server 2000 does not). > > (And as Pascal explained, this connection string has to identify > the target DBMS.) > > To implement support for this mere string, those complexities > has to be solved. > > Atsushi Eno > > > bryan costanich wrote: > > Hi all, > > > > In working with the generated c# LINQ classes from DBMetal, i've > > noticed that the two DataContext constructors both require an > > IDbConnection, whereas the .net ones also allow you to pass among > > other things, just a connection string. > > > > Looking into it, i see that the underlying DBLinq.DataContext class > > actually has the constructors there, but they're unimplemented. they > > are a little different though. they expect a > > "fileOrServerOrConnection" string. but i'm not sure even what that > > means. > > > > I think this should be added for a couple reasons. 1) to preserve > > fidelity with the .net implementation, and 2) it's really damn useful. > > > > in thinking about maybe adding this, some questions popped up, namely: > > -> what is the intent here, i believe the .net version supports only > > valid db connection strings > > -> if we get something in here, how do we determine the correct way to > > initialize the connection, e.g. do we parse the 'provider'? what if > > there is none? is there a standard here we should be looking at, e.g. > > only valid .net connection strings? > > > > for now, personally, all i care about is mySQL, so i'm happy to throw > > something in there that parses a valid .net connection string and if > > the provider is DBLinq.MySql (or whatever it should be called), then > > create a MySQL Connection, otherwise it would just throw an exception > > - would that piss anyone off? > > > > perhaps i'm not the best person to be doing this, since i'm not > > intimately familiar with the project, so if someone else wants to, > > that would be even better, but i would like to use it soon. > > > > thoughts? > > > > -b > > > > > > > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
