On Mon, 2010-02-22 at 13:49 -0800, Ej wrote:
> I am using PostgreSql (on OpenSuse 11.2) for my data base and Mono 2.6
> (which utilizes DBLinq to Provide the linq to sql functionality). I
> can successfully connect to the database and retrieve records by
> executing queries via the data context. IE:
>
> var dc = new DataContext(new NpgsqlConnection (connectionString));
>
> foreach(Course course in dc.ExecuteQuery<Course>("Select * From
> Course;"))
> {
> Console.WriteLine (course.courseName);
> }
>
> successfully prints out the names of the courses stored in the
> database.
I should hope so -- you're not actually going through any of the SQL
generation code of DbLinq!
> However I cannot access the same data using the GetTable method:
>
> foreach(Course course in dc.GetTable<Course>())
> {
> Console.WriteLine (course.courseName);
> }
>
> which yields:
>
> Unhandled Exception: Npgsql.NpgsqlException:
> syntax error at or near "["
> Severity: ERROR
> Code: 42601
> at Npgsql.NpgsqlConnector.CheckErrors () [0x00027] in /usr/src/
> packages/BUILD/mono-2.6.1/mcs/class/Npgsql/Npgsql/NpgsqlConnector.cs:
> 361
Right.
> Having had a look around, the biggest clue I have found is that
> implementations not based on Mono 2.6, (IE using Dblinq directly) use
> an assembly: DbLinq.Postgres.dll. My project currently references
> Npgsql, System, System.Core, System.Data, and System.Data.Linq. Is
> DbLinq.Postgres.dll missing from the Mono implementation? Do I need
> to obtain this separately?
No/Maybe/fog-where-are-you?
/me kicks himself for not documenting this anywhere...
So, DbLinq contains a core library (DbLinq.dll) and per-dialect
assemblies (e.g. DbLinq.Postgres.dll). For Mono, all of these
per-database assemblies are merged into System.Data.Linq.dll.
Thus, to answer your first question, Mono doesn't need a separate
DbLinq.Postgres.dll, as the contents of that assembly are within
System.Data.Linq.dll.
This raises Question 2: how does Mono's System.Data.Linq.dll know which
SQL dialect to generate at runtime? This is why you're getting a
'syntax error' from Npgsql -- Microsoft SQL Server dialect SQL is being
generated, not PostgreSQL dialect SQL.
Answer 2: We use a "DbLinqProvider" parameter within the connection
string to determine which SQL dialect to generate; see
http://www.jprl.com/Blog/archive/development/mono/2009/Mar-12.html
If the DbLinqProvider parameter isn't present, then Microsoft SQL Server
is assumed (which, again, results in your error).
However, this now raises:
http://code.google.com/p/dblinq2007/issues/detail?id=177
in which Npgsql apparently mangles the casing of additional parameters
(uppercasing it to DBLINQPROVIDER), which prevents DbLinq from finding
the value. Oops.
For now, try adding a DbLinqProvider=PostgreSql key/value pair to your
connection string, and pray that this works. :-)
If it doesn't work, you would need to patch your System.Data.Linq.dll,
which (given that you're using pre-built packages) is likely out of the
question.
(I also vaguely recall that recent Npgsql's will throw an
exception if you try to stuff "unsupported" key/value pairs into
the connection string -- which renders DbLinqProvider useless,
with no workaround.
Thus, Question 3: Is my memory faulty? I thought this was a
filed bug, but issue 177 is the closest I find, so perhaps
Npgsql will support "unsupported" key/value pairs.)
Failing all that, you can just build DbLinq under Mono and use it
"normally" -- DbLinq.Data.Linq.DataContext has a constructor that
accepts an IVendor parameter, which allows you to explicitly specify
which SQL dialect to use w/o needing to use a connection string
parameter. (Unfortunately System.Data.Linq can't do this, as it would
be an incompatible API addition.)
- Jon
--
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.
