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