3 ms·

a sproc tends to be written directly on the database server ... Copying it to the fs before committing your changes is a step that people often forget No they

a sproc tends to be written directly on the database server ... Copying it to the fs before committing your changes is a step that people often forget No they don't. At least not more than once. Changing something on your dev database and forgetting to save your change scripts and check them in is analogous to changing html directly on the production web server and forgetting to save it locally and check it in to source control. It's a very bad idea, and nobody would ever actually do that. But if you did do it, your changes would evaporate during the next deploy, and after a few minutes of venting to the sky you'd learn to never ever do that again.

cameronh90 15y ago
Except my IDE doesn't require me to be editing while connected to the server to get all the useful refactoring/etc. tools. It only requires being attached to debug. Admittedly in most SQL editors, you can open up the file, then connect the IDE to the database. But it's hardly seamless (particularly if you have multiple databases), and certainly isn't like normal development where the filesystem is exactly what's running, and is the only user visible copy. The tools just all feel extremely immature compared to any IDE I've used. And to clarify, I'm talking about the dev SQL server, not developing in production.
- jasonkester 15y ago
  Right, but we're not talking about IDEs. We're talking about SQL. No matter what you use to modify your database, be it a modeling tool, the table editor that comes with the database, a fancy VS.NET plugin, or a mysql command prompt, you're still producing SQL change scripts. Those change scripts always need to get saved out to a file and checked into source control. This is especially true if you're developing on a local database with multiple stages between you and production. You need scripts for everything so that your build can push things out to the next environment down the chain and eventually live. If you're not doing that, I can't imagine the pain you're introducing for yourself.

cameronh90 15y ago

Except my IDE doesn't require me to be editing while connected to the server to get all the useful refactoring/etc. tools. It only requires being attached to debug. Admittedly in most SQL editors, you can open up the file, then connect the IDE to the database. But it's hardly seamless (particularly if you have multiple databases), and certainly isn't like normal development where the filesystem is exactly what's running, and is the only user visible copy. The tools just all feel extremely immature compared to any IDE I've used. And to clarify, I'm talking about the dev SQL server, not developing in production.

jasonkester 15y ago
Right, but we're not talking about IDEs. We're talking about SQL. No matter what you use to modify your database, be it a modeling tool, the table editor that comes with the database, a fancy VS.NET plugin, or a mysql command prompt, you're still producing SQL change scripts. Those change scripts always need to get saved out to a file and checked into source control. This is especially true if you're developing on a local database with multiple stages between you and production. You need scripts for everything so that your build can push things out to the next environment down the chain and eventually live. If you're not doing that, I can't imagine the pain you're introducing for yourself.