Create Database programmatically

  • Thread starter Thread starter __Z__
  • Start date Start date
Z

__Z__

Datasets/tables can be created programmatically with C# or VB.NET and
written to an existing database...

But is there any way to create the database itself within a C# program
(without embedding lots of SQL commands).
 
Either use the DMO programming API. It gives you an object model on top of a
lot of management-type SQL commands (like create database, create table etc
etc) Essentially, EM is a "visualsation" of the DMO object model.
Or just your current API and execute the CREATE DATABASE statement (assuming
you use ADO.NET, you can use ExecuteNonQuery).
 
On Thu, 06 Nov 2003 07:16:49 GMT, "Tibor Karaszi"
Either use the DMO programming API. It gives you an object model on top of a
lot of management-type SQL commands (like create database, create table etc
etc) Essentially, EM is a "visualsation" of the DMO object model.
Or just your current API and execute the CREATE DATABASE statement (assuming
you use ADO.NET, you can use ExecuteNonQuery).
Click to expand...

Thanks for your reply, Tibor. I'll check into DMO. That sounds
closer to the approach I want to take. (Any reason NOT to use DMO?)

For now, I've tried issuing SQL commands inside the program, and I was
surprised that the initial connect string worked without having to
specify a database. So I was able to get the db created.

I did run into a glitch when trying to delete it in the same fashion
(connect string with no db specified). Exception says that the db is
in use, despite my having issued a close. Not sure what is going on
there.
 
Thanks for your reply, Tibor. I'll check into DMO. That sounds
closer to the approach I want to take. (Any reason NOT to use DMO?)
Click to expand...

You're welcome :-). Personally, I prefer to send TSQL command, as I see no
real reason to abstract the TSQL commands with ah object layer. Regarding
future compatibility; it is a two way street; TSQL command can change but
object layer stay the same (abstracts the change) but also object layer can
change. MS has indicated that there will be a new object layer in Yukon, but
I'd be surprised if they didn't keep DMO at current level for compatibility
reasons.

For now, I've tried issuing SQL commands inside the program, and I was
surprised that the initial connect string worked without having to
specify a database. So I was able to get the db created.
Click to expand...

You probably ended up inside your default database for your login.

I did run into a glitch when trying to delete it in the same fashion
(connect string with no db specified). Exception says that the db is
in use, despite my having issued a close. Not sure what is going on
there.
Click to expand...

Did you do USE database inside your app? Perhaps the connection was still
hanging around and that kept you from deleting the database? Try USE master
before closing connection. Check using sp_who, sp_who2 etc.
 
hi,
__Z__ said:
Thanks for your reply, Tibor. I'll check into DMO. That sounds
closer to the approach I want to take. (Any reason NOT to use DMO?)
Click to expand...

a strong caveat derives from MSDE installations, where only the server will
have all SQL-DMO dependencies installed, but all clients usually only have
MDAC installed...
MDAC does not provide SQL-DMO dependencies installation, but as per
http://www.microsoft.com/sql/msde/howtobuy/msdeuse.asp
you are legitimate to distribute them along with your application
installation
Andrea Montanari (Microsoft MVP - SQL Server)
(e-mail address removed)
http://www.asql.biz/DbaMgr.shtm http://italy.mvps.org
DbaMgr2k ver 0.4.0 - DbaMgr ver 0.50.0
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
--------- remove DMO to reply
 
Back
Top