Chicken or Egg: SQL vs Strongly Typed DataSet

  • Thread starter Thread starter _eddie_
  • Start date Start date
E

_eddie_

I'm still trying to figure out the best way to approach this problem:

I have to create a (SQL server) database and tables within C# code
(Ado.net) and then create a strongly typed dataset from that table...
Or is the reverse possible? It would seem that there's enough info in
a strongly typed dataset to create the database/tables.

I haven't seen this mentioned in books on ADO.net, possibly because
they usually use pre-existing db's for their examples. But it's a
problem that should come up quite a bit in production code. I do need
to create everything from inside the C# code, so I'd like to avoid
coding lots of embedded SQL if possible.

It does look like a chicken or egg problem: If the SQL Server table
already exists, then it's a snap to create the dataset. But alas, it
does not exist yet (on the target installations, anyway).
 
ADO.NET has no facility to create database tables--even from strongly typed
DataSets.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
 
Hi,

As Bill said there is no built in support. Which doesn't mean the it can't
be done though.
If you have strong typed datatable and it doesn't exisit yet in server, you
might use the instance (TableName, Columns collection) properties to create
a DDL command and send it to Sql server to create table.
Or, you might use ADOX to build your table.
 
I'm still trying to figure out the best way to approach this problem:

I have to create a (SQL server) database and tables within C# code
(Ado.net) and then create a strongly typed dataset from that table...
Or is the reverse possible? It would seem that there's enough info in
a strongly typed dataset to create the database/tables.

I haven't seen this mentioned in books on ADO.net, possibly because
they usually use pre-existing db's for their examples. But it's a
problem that should come up quite a bit in production code. I do need
to create everything from inside the C# code, so I'd like to avoid
coding lots of embedded SQL if possible.

It does look like a chicken or egg problem: If the SQL Server table
already exists, then it's a snap to create the dataset. But alas, it
does not exist yet (on the target installations, anyway).
Click to expand...

You can execute DDL of course through ADO.NET. However I'd suggest
you reference SQL-DMO, the library of SqlServer which contains all
management objects. (It's a com lib but works with C# as well). Create
your database objects using SQL-DMO, and execute your dataset filling code
using normal ADO.NET

FB
 
but will SQL-DMO be around in Yukon or will we need to change the code
again?

dlr
 
ADO.NET has no facility to create database tables--even from strongly typed
DataSets.
Click to expand...

Surprising, considering the amount of automatic code generation in
VS.NET! You'd think they could have written some code to do this
easily.

I've also been looking for code to generate Connection strings. I did
figure out how to use the same dialog that VS.NET uses, but it appears
that this is still Com code. Still a bit awkward for distribution.
 
That code is in the designers. I expect MS thought that it's the purview of
the tools to do the DDL--VS.NET provides some of those tools, SQL EM more,
SQL-DMO even more. ADOX is a COM-based throwback that works best for JET.
Yes, it's tough to get the Framework to do this, but I expect there are also
third-party tools you can use.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
 
I am pretty sure DMO got a total re-write in Yukon.
Not sure if old code is compatible.
--
Joe Fallon



Dennis Redfield said:
but will SQL-DMO be around in Yukon or will we need to change the code
again?

dlr
Click to expand...
 
In Yukon, SQL-DMO is supported but SMO (System Maintenance Objects) are to
replace it.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
 
Back
Top