I really don't recommend this. Actually, LINQ-to-SQL has a tough
enough time with SQL Server 2000 that I can't even advocate using it
on anything less that SQL Server 2005; the lack of "common table
expressions" means that you can break it easily if you do a "skip" or
"take" on a fairly trivial composite query; I posted some examples
(along with the generated SQL from 2000 and 2005) towards the end of
last year.
Even if you get it "just about" working, I strongly suspect that it
will be brittle, and you will keep hitting more and more problems as
you develop.
But isn't SQL Server 7 officially obsolete? I haven't checked, but I
would have thought it dead by now... I don't think it is unreasonable
to have a cutoff point to say: we're not going to even *try* and make
it work on this - especially with the language differences.
There are other LINQ providers that *might* work; I've never used
them, so not a direct recommendation...
LLBLGen is meant to have LINQ now or soon; DbLinq is another, but from
discussions here, I'm not sure that it is very robust yet... not that
I'd be a big fan either way (unless it did something *demonstrably*
better than LINQ-to-SQL or "EF", what is the point?)
Marc
Dmitry Perets - 13 Apr 2008 08:48 GMT
Hi,
Thank you for your reply. Of course, you are right, SQL Server 7 is
extremely obsolete. Unfortunately, legacy issues still exist =( And we
actually have two options: we can work with typed datasets or we can
try to work with LINQ to SQL. Well, for now I prefer the latter.
Anyway, if there are some horrible problems we can always switch to
the typed datasets. The application is multi-tier of course, so this
change will be local and minimal...
Frans Bouma [C# MVP] - 13 Apr 2008 09:53 GMT
> I really don't recommend this. Actually, LINQ-to-SQL has a tough
> enough time with SQL Server 2000 that I can't even advocate using it
[quoted text clipped - 3 lines]
> (along with the generated SQL from 2000 and 2005) towards the end of
> last year.
general #temp table paging queries are very fast as well in general
scenarios. As long as you setup the tempdb properly (which you should
anyway) it's not a problem. I don't know if Linq to sql does proper
paging at all on db's below 2005.
FB

Signature
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
> Hello,
>
[quoted text clipped - 6 lines]
> Provider for OLE DB. Well, at least, ServerExplorer can't connect to
> SQL Server 7 using .NET Provider for SQL Server...
SqlServer 7 has a problem in the stored procedure meta data retrieval
area: it lacks certain INFORMATION_SCHEMA views. With OleDb this
meta-data is still retrievable.
It's a couple of lines of code (100 or so). I find it a bit surprising
MS couldn't find the time to write that code for sqlserver7 users.
> Now the interesting thing is that this is a designer's problem only!
> Actually LINQ to SQL do can communicate with SQL Server 7 without any
[quoted text clipped - 13 lines]
> }
> }
of course :) Sqlserver 7 and 2000 don't differ that much in general
usage of data with CRUD SQL only.
FB

Signature
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
Dmitry Perets - 13 Apr 2008 13:23 GMT
On Apr 13, 10:50 am, "Frans Bouma [C# MVP]"
<perseus.usenetNOS...@xs4all.nl> wrote:
> DmitryPeretswrote:
> > Hello,
[quoted text clipped - 34 lines]
>
> of course :) Sqlserver 7 and 2000 don't differ that much in general
Frans Bouma, thank you for your explanation. Do you know how I can
make the LINQ designer work then? Because as we see, LINQ actually can
work with SQL Server 7! So the only problem is that designer's
check...
The alternative way is to make the Server Explorer use SQL Server
Provider and not the OLE DB - I don't care about the stored
procedures, I need only tables. But again, the GUI doesn't allow me to
do that saying that SQL Server provider works for SQL Server 2000+.
And we know that this is not true actually...
> usage of data with CRUD SQL only.
>
[quoted text clipped - 9 lines]
>
> - Show quoted text -
Frans Bouma [C# MVP] - 14 Apr 2008 09:09 GMT
> On Apr 13, 10:50 am, "Frans Bouma [C# MVP]"
> <perseus.usenetNOS...@xs4all.nl> wrote:
[quoted text clipped - 44 lines]
> work with SQL Server 7! So the only problem is that designer's
> check...
I have no idea. Microsoft apparently build in some restrictions in
their designer.
So you either should use another o/r mapper or use another database.
One 'workaround' could be that you create your project on a sqlserver
2000/2005/express catalog with the same name/table layout and then use
that at runtime against the sqlserver 7 catalog.
FB

Signature
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------