I have a Desktop application that uses Linq To SQL as the DAL. It accesses a local SQL Express DB.
If I have a SQL CE DB that has the Exact same schema(table structure) can I re-use the generated dbml with just giving it a different connection string?
This article on LINQ To SQL on SQL CE from Matt Manela suggests that you could replace your SQL Server Express connection string with a connection string to SQL Server CE without any large issues. If it's just table-level querying that you're interested in, it sounds like you'll be in good shape.
He points out though, that CE handles connections differently than the larger SQL Server editions.
Without having tested it myself, I'd only want to determine if LINQ To SQL would ever generate any TSQL statements using keywords or features that SQL CE didn't support.
Also note, the current release does not support stored procedures or the XML datatype. It uses a subset of TSQL.
Best to visit the official .NET 3.5 SP1 LINQ To SQL for SQL Server Compact page at Microsoft.
Related
I have a Microsoft SQL Server database(tables, relationships and data).
But now I want an exact same copy of this database in Oracle.
I was thinking there may be some sort of a tool or converter that could generate Oracle sql scripts that I could run to create and populate my new Oracle database.
Is this kind of thing possible?
And how can I achieve this ?
Your best bet is to use a DB modelling tool which can reverse engineer your SQL Server database and then generate a script to recreate it in Oracle.
DB Designer Fork can do this for you and is Open Source.
Are there any tools that I can use to migrate my Oracle database to SQL Server 2008? If not what are other choices for this type of migration?
With migration I need to move only tables (with all indexes and constraints) and data. There are no any functions, views or stored procedures.
See e.g.
Microsoft SQL Server Migration Assistant (SSMA) for Oracle is a free tool for migrating Oracle databases to Microsoft SQL Server. SSMA for Oracle converts Oracle database objects (including stored procedures) to SQL Server database objects, loads those objects into SQL Server, migrates data from Oracle to SQL Server, and then validates the migration of code and data.
http://www.microsoft.com/sqlserver/2005/en/us/migration-oracle.aspx
or many more commercial offerings - Bing or Google are your friends!
I am trying to migrate my Oracle db to SqlServer 2008 using SSMA. I defined some type mappings for columns. When I synchronize after converting schema it gives errors like: "Cannot find datatype datetime" or bit. These datatypes are valid SQL Server datatypes.
Why I am getting these errors?
Just a guess, but it's quite hard to provide more than that before you give more details... (the code being synchronized to SQL Server, first of all).
Do you have case-sensitive collation on your SQL Server? I believe SSMA may have problems in this case. Try synchronizing to case-insensitive DB.
Also you may try running generated SQL Server (translated) code in the Management Studio and then find the problem with generated SQL or DB setup from that point. Again, it's most likely possible to figure out the problem solely by looking at your generated SQL if it's indeed corrupted due to some bug in SSMA.
I am converting some code from VB RDO (using an ODBC cursor) to ADO.NET
Some of the old VB code loops through the RDO errors collection to get any ODBC or Server errors and log them accordingly.
I've converted the code using Data.Common objects (ex: DBCOnnection, DBCommand) and using Datasets and ODBC. (I am NOT using Oracle .NET Provider)
What is the best way to approach this scenario? How do I get server or ODBC errors in this fashion. There is no errors collection I can use. Should I be using Try/Catch? Any best practices? or knowledge from experience?
Linq To SQL or Entity framework both integrate nicely with SQL Server 2005.
The SQL Server 2008 spec sheet promises even better integration - but I can't see it.
What are some examples of what you can do Linq-wise when talking to a 2008 server that you can't when talking to SQL Server 2005?
This marketing link claims
"Write data access code directly against a Microsoft SQL Server database, using LINQ to SQL."
Which is basically untrue.
Linq To SQL is query comprehension translated into expression trees translated into SQL, optimized by the query optimizer and then run against SQL Server database. "directly" feh.
There is a problem of paging over a joined set that SQL 2005 mis-interprets.
var orders = (
from c in Customers
from o in c.Orders
select new {c, o}
).Skip(10).Take(10).ToList();
LINQ generates a ROW_Number against the joined set. SQL2005 generates a bad plan from that code. Here's a link to the discussion.
Edit#2: I'd like to clarify that I don't know that SQL2008 solves this problem. I'm just hopeful.
it has full support for the new data types. lol. beyond that you got me, other than possibilities of optimised queries (like the merge command, etc).
I am guessing most of it has to do on the server anyways. They probably optimized the query execution as for differences I don't know except for the new types.
Unless LINQ exposes the new MERGE statement, no.
There is little effective difference in the engines especially from an ORM/client view