Special LINQ group available?

[Neil]

Hi group,

is there a special C# LINQ group available?

Regards

 

[Marc Gravell]

There are a few managed forums for LINQ, but various people here can
probably assist too...

The LINQ Projecft General managed forum is here (at least until the big
move):
http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=123&SiteID=1

Marc

 

[Neil]

Hi Marc,

thanks for your answer. Because I love good old NNTP groups, I'll try to get
an answer to my question here first

The problem seems to be rather simple: I have a VS 2008 WinForm app, using a
local database (SDF file). One of the tables contains a DateTime value. Now
I was trying to query for the DayOfWeek of the given date using

var absences = context.Absences.OrderBy(o => o.Date).Select(o => new {
o.Department, o.Name, o.Date.Month, o.Date.DayOfWeek, o.Reason });

what results in the following SQL statement:

SELECT [t0].[department] AS [Department], [t0].[name] AS [Name],
DATEPART(Month, [t0].[date]) AS [Month], CONVERT(Int,(DATEPART(dw,
[t0].[date]) + (@@DATEFIRST) + 6) % 7) AS [DayOfWeek], [t0].[reason] AS
[Reason]
FROM [Absence] AS [t0]
ORDER BY [t0].[date]

While trying to iterate through absences using the well known "foreach (var
item in absences) { }" I' catching the following exception:

{"The global variable name is not valid. [ Global variable Name =
@@DATEFIRST ]"}

The question is: How to add @@DATEFIRST to my SQL compact edition database?

Regards

 

[Marc Gravell]

Intersting... I didn't know that @@DATEFIRST didn't work on SQL CE,
but then - I didn't know that LINQ-to-SQL *did* work on SQL CE ;-p

You could perhaps try just selecting the date (o.Date) from the
database (perhaps calling ToList() or ToArray() to buffer it locally),
then do a second projection afterwards?

var tmp = context.Absences.OrderBy(o => o.Date).Select(o => new {
o.Department, o.Name, o.Date, o.Reason }).ToArray();

var absenses = tmp.Select(o => new {
o.Department, o.Name, o.Date.Month, o.Date.DayOfWeek,
o.Reason });

That might fix it?

Marc

 

[Neil]

Oh, that's a great idea, and indeed - it works
I already managed to do the .DayOfWeek things in the iteration loop, but
your solution is much smarter than this.

Great.

Yes, Linq-to-SQL does work on SQL CE perfectly. But it doesn't work
automatically. You have to manually "SQL-metalize" the database, whenever
you change the table layout. There is a couple of blogs out, describing this
issue. The tool "sqlmetal.exe", required for this, is available in the SDK.
(Program Files\Microsoft SDKs\Windows\v6.0A\bin)

In my case I always run

SqlMetal.exe Database.sdf /dbml:KS.dbml /namespace:KS /pluralize

This produces KS.dbml, which I import into my project every time it is
changed (delete/add). The KS.designer.cs then contains all the classes
required for nice and smart "CRUDs". Because the structure of my db doesn't
change that frequently I can live with this small manual interaction.
I never worked with a SQL database easier.

Regards and thanks again for your assistance
Neil.

 

[Marc Gravell]

Re sqlmetal - I've found that most incrememtal changes are easier
simply by editing the dbml directly. Fortunately LINQ-to-SQL has
simple markup - I wouldn't try this with Entity Framework - but then
EF includes better tooling for database changes (which still doesn't
help very much if the designer doesn't like your database...).

One other trick I've used (in similar scenarios to the SQL CE) is to
setup the database on something that the designer DOES like [SQL
Express being the obvious choice], then just supply a different
connection string at runtime. That way you get the richer designer
experience, while still running against your chosen platform
(fortuantely the decisions about SQL dialects is made at runtime, not
compile/design time).

Marc

 

[Neil.Young]

Oh, sorry. Seems you know more about that than me

From your statement

but then - I didn't know that LINQ-to-SQL *did* work on SQL CE ;-p

I didn't expect, that you would have _any_ experiences with SQL CE.

Kind reagards

Re sqlmetal - I've found that most incrememtal changes are easier
simply by editing the dbml directly. Fortunately LINQ-to-SQL has
simple markup - I wouldn't try this with Entity Framework - but then
EF includes better tooling for database changes (which still doesn't
help very much if the designer doesn't like your database...).

One other trick I've used (in similar scenarios to the SQL CE) is to
setup the database on something that the designer DOES like [SQL
Express being the obvious choice], then just supply a different
connection string at runtime. That way you get the richer designer
experience, while still running against your chosen platform
(fortuantely the decisions about SQL dialects is made at runtime, not
compile/design time).

Marc