[dba-SQLServer] QLRE: Copy a database using a stored procedureor function

jwcolby jwcolby at colbyconsulting.com
Tue Mar 25 20:26:28 CDT 2008


Paul, 

You have been immensely helpful already, and I certainly don't mean to
denigrate your abilities.  You obviously know your stuff.  I understand data
store concepts but the BE is just one (small) part of an application.  

I have designed systems with hundreds of tables, one such system was used by
a company that built cell towers, start to finish, from buying / leasing
land to constructing the towers, to maintaining the systems once built.  It
had FIVE completely different Fes for different divisions of the company.
Another such system is an entire call center for a company that handles
disability insurance claims.

The point is that the data store is just part of the whole thing and while
it is AN important part, it is only ONE important part.

It would appear that you have focused on the data store and getting that
down to an art, and I applaud your abilities, but the tools you need are not
the tools I need.  That is all I am saying.  I am here on this forum as a
know nothing nubee, who will NEVER know 1/100th what you know ABOUT SQL
SERVER.  That is just reality and I am not sad about that.  I love what I do
just like you love what you do.

I just need someone's help figuring out the tiny little pieces that I need
SQL Server to do.  Trying to make me a SQL Server guru is like trying to
teach the pig to sing.  It isn't going to happen, and it pisses off the pig.

And yea, I am more than a little unhappy about how hard it is to do the
slightest little thing in SQL Server.  I have to tell you, I have spent more
time getting less done in SQL Server than I have spent getting a whole load
done in .NET, and I have to also say that .Net is a complex system.  Just
the nature of the beast I guess.  Luckily I have a raft of very
knowledgeable people on this list to help me figure this stuff out and get
back to what I should be doing.

Thanks again for all your help as well as the suggestions from everyone else
on the list.  

John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Paul
Nielsen
Sent: Tuesday, March 25, 2008 7:38 PM
To: 'Discussion concerning MS SQL Server'
Subject: Re: [dba-SQLServer] QLRE: Copy a database using a stored
procedureor function

Hi John,

Sounds like you have a lot to do. 

I build entire SQL Server back-ends in days/weeks much like you've figured
out the best way to build entire Access apps in days/weeks. I was trying to
show you the fastest and safest way to develop client-server code and then
deploy across multiple servers. Moving databases or objects using back-ups
or scripting out objects saved only in the database is a real pain and error
prone. Coding with SSMS/Query Editor and then saving the script makes it
easier and faster. But if that's not style, no problem. 

If you ever do need a proc written or any T-SQL help, I'd love to help you,

Cheers,
-Paul 


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Tuesday, March 25, 2008 2:52 PM
To: 'Discussion concerning MS SQL Server'
Subject: [dba-SQLServer] QLRE: Copy a database usinga storeprocedure
orfunction

No Paul, you don't get it.  I don't want to code Sql server at all.  I
certainly don't want to edit a file on a directory in TSQL.  

I also don't want to go open a stall door, lead a horse out, put a harness
on it, hitch it up to my wagon, climb up and sit on a board and spend the
next hour bruising my butt getting three miles to the center of town.

Luckily I have a car.  Unfortunately I am still writing TSQL in SQL Server.

When you understand how TSQL equates to a horse and wagon you will
understand what I mean.  You are hitching up a wagon each time you do
anything in SQL Server and the sad part is, you shouldn't have to.

I can build entire systems in VB or Access in a matter of days or weeks.
Reams of forms, reports, queries.  Code that allows me to connect to the
internet, download files from an FTP site, open the files, import them into
the database, export the data back out, attach them to emails and send
results off to clients.  Writing SQL at all is a total waste of (my) time.

15 years ago designing one single form took days and weeks of programming in
c++.  Now I can drag and drop objects out onto forms, set properties, 
c++bind
them to data, enter data, see the data, report the data in hours.

You are still living in the "weeks to do a form" era, and you obviously like
it, and that is fine... for you.  It is not fine for me because I make my
living doing stuff quickly.

Please, do not EVER suggest to me editing TSQL in files on a disk.  The
probability that I will even read the post is somewhere between 0 and
negative infinity, and rapidly approaching negative infinity.

I'm trying to get WORK done here.  

Work BTW is not writing TSQL.  Work is receiving a job in an excel
spreadsheet attached to an email, creating a directory structure on my hard
drive to hold the pieces and parts, saving the order spreadsheet into that
directory structure, copying the SQL Server template database,  modifying a
view in the copied database to pull the right records, exporting the data to
a CSV file on an address validation server, processing that CSV file through
a third party Address Validation software, reloading the cleaned data (CSV
file) into SQL Server, deduping the addresses, selecting a random set N of
those address, Exporting them to a flat file, marking them as exported,
zipping the flat file and FTPing it or attaching it to an email, then
emailing the clients telling them the order went out.

All with a minimum of my time spent.  It should take me 1/2 hour (of my
time, MAXIMUM) to do all of that stuff.

Do we see how I truly do NOT want to be writing SQL (in a file on a
DISK!!!)?  Do we see how spending years learning TSQL AT ALL is not in the
cards?  I don't want to learn TSQL, I don't want to WRITE TSQL, I want to
build an application that builds my orders from a few pieces of information
typed into a form, logs the processor time used for the various tasks into
tables, executes the order, transmits the order to the client, computes a
bill for my processing time, and emails the bill to the client.  

In fact I REALLY want the client to type his own damned order information
into a form on the internet, and receive his order and a bill for my
processor time over the internet.  

;-)

John W. Colby
Colby Consulting
www.ColbyConsulting.com
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Paul
Nielsen
Sent: Tuesday, March 25, 2008 4:08 PM
To: 'Discussion concerning MS SQL Server'
Subject: Re: [dba-SQLServer] Copy a database usinga storeprocedure
orfunction

Source code belongs in source code control. Developing in a gui is just
plain dangerous. 

All I'm saying is that when you code the sproc, do it in query editor and
then save the file. Don't use Object Explorer to create new proc, save it in
the database and then edit it by opening it from the database. It's the same
code, the difference is that the database is the destination of the code,
not where you keep it. You keep the code in source control. 

I do all my development from files in directories that I open, edit, and
then run. It's the fastest way to develop with SQL Server. 

If you develop with multiple databases and multiple severs then you really
need to work this way. You open you file, connect to whichever server you
want, and then press F5. It's fast, simple, and easy. 

In SQL Server lingo, any submission to the database is a batch. If you
highlight a query and press F5 - that's a batch. If the batch is saved in
the database, that's a stored proc. If you've been working with SQL Server
you've been doing batches. The question is only where do you want to save
your source code? 

-Paul 

_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com


__________ NOD32 2971 (20080325) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com


_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com




More information about the dba-SQLServer mailing list