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.Absence s.OrderBy(o =o.Date).Select (o =new {
o.Department, o.Name, o.Date, o.Reason }).ToArray();
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.e xe", required for this, is available in the SDK.
(Program Files\Microsoft SDKs\Windows\v6 .0A\bin)
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" <marc.gravell@g mail.comschrieb im Newsbeitrag
news:7de3b04c-b835-4b29-ac80-6b57e4f8978b@l4 2g2000hsc.googl egroups.com...
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.Absence s.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.DayOfWee k,
o.Reason });
>
That might fix it?
>
Marc
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).
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
"Marc Gravell" <marc.gravell@g mail.comschrieb im Newsbeitrag
news:057edcd4-26f9-4461-82c6-fcf8af91b515@c6 5g2000hsa.googl egroups.com...
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
Comment