Migrated SQL Express to a viable DB. Easy? Hard?

  • Thread starter Thread starter darrel
  • Start date Start date
D

darrel

I haven't been able to play in ASP.net 2.0 as much as I'd have liked to this
past year. I'm going to start a new project from scratch in 2.0, however, so
am looking forward to that.

I'd like to know how hard would it be to built the solution locally using
the built-in SQL Express, and then migrated that to the product server? Is
it a rather simply process? Complex? Any specific guides/tutorials on how to
do it?

Ideally I'd be going to from Express to MS SQL, but what if I went to MySQL?
Still viable? Of coruse, if I was using MySQL, I suppose I could just
install that locally.

-Darrel
 
If it is SQL Server Express to full SQL Server 2005, it is as simple as
attach/detach or backup/restore the *.mdf/*.ldf file from your computer to
production server. THere may be SQL login/database user problem (that is,
SQL login/database user exist on one computer, but not on the other
computer), which can be fixed easily, if you know SQL Server well (since you
are going to use it, you are going to know it well, aren't you?).

As for from SQL Server Express to MySQL, since they are two different
database server product, there are differences. if it is viable, depends on
how much you know both,how many features you used that available in one but
not in the other. The bottom line is it would be harder than moving from SQL
Server express to SQL Server2005.
 
Personally, I do EVERYTHING via tsql scripts.

And whether the database is Express, Developer , or a full Enterprise
version, I run those tsql scripts against that database.
(This assumes Sql Server 2005).

I did this same thing with MSDE, Developer and Enterprise versions of
SqlServer 2000.


Esp if you know you might migrate, then coding out the tsql would be
beneficial.

....

MySQL? No idea. But you'd have to write some very generic ansi sql code
(for the most part) to do this.

Personally, I wouldn't suggest this route. You dev environment should be
just about the same as deployment environment.
 
Personally, I do EVERYTHING via tsql scripts.

Are you referring to stored procedures? I'm not sure what a 'tsql script'
is. Honestly, I know just enough about SQL to be dangerous. ;o)
Personally, I wouldn't suggest this route. You dev environment should be
just about the same as deployment environment.
Click to expand...

Agreed. I think I'll tell'em I'm moving forward with MS SQL and if they
change their mind half way through, we'll have to reevaluate the schedule
and budget at that time.

-Darrel
 
Everything, as in.

DDL

"Create Table dbo.Department"

Alter Table dbo.Department (for in production changes if necessary)


usp's
udf's
view's
triggers


Assign priv's to those tables, usp's, udf's, views, etc.


And sometimes even the "Use Master GO Create Database SchoolInfoDB" , as an
example.

If you download the northwind/pubs 2000 examples from microsoft, you can see
how they figure out the /Data/ directory and put the datafiles in there (for
a Create Database), which is pretty nifty.

...

But what I mean is I never do things through the GUI. If I need to change a
column to be nullable for example, I don't "uncheck the allow-nulls
checkbox". I write the tsql script.

Working in a group environment, and having development / staging /
production servers, I feel IMHO is a best practice.
 
Back
Top