in

ASP.NET Weblogs

uber1024's WebLog

It's not hot wings and beer, but it's still okay

Feature I want to see more than anything in the universe

When I look at every software product I've EVER used in my entire life, the feature that I want to see the most is a "Last Modified Date" for stored procedures in SQL Server.

Why is that so freakin' hard?  Why does nearly every other product on the planet have a last modified date for nearly everything, yet SQL Server does not?!

As a developer, I take software for what it is.  You'll rarely hear me rant about Windows, Linux, IE, Firefox, VB, .NET, or even Java, but THIS is the one thing that drives me up a wall.  Has anyone from Microsoft EVER used SQL Server?  Have they ever tried to manage a database-driven project that lasts more than a few months?  It just doesn't make sense that this wouldn't be a feature.

Anyway, it's only because I use SQL Server almost every day (and I really like it) that this bothers me.

Comments

 

Scott Prugh said:

I agree that this is ridiculous. It would at least make DB versioning approachable. I always believed that DB versioining should have been built into Sql Server at the core to track all changes. This would really eas the dev cycle.

Anyways, Yukon has something that can help. You can creat triggers to track DB changes. In the trigger you get hannded the DML. You can then write this to a table. It makes a workable solution.
May 11, 2005 6:42 PM
 

Gabe Halsmer said:


I would think that for any enterprise application, and by that I mean an app that changes a lot and lives on for years, you'd want all of your stored procedures to be SQL files. That way you can version them with VSS and keep them with the rest of the source code.

I'm not sure if you want to deploy the SQL as your compile your projects or if it should be deployed when the code first runs. For example, most enterprise apps have 1 or more staging areas between the developer's local test environment and the production environment. If you want to keep deployment simple, like copying dll assemblies from one environment to the next, then you'll want the dlls to be smart enough to run the SQL the 1st time they're used in the new environment.

:) Or of course you could just use dynamic SQL instead of stroed-procs, but I won't go there.
May 11, 2005 7:09 PM
 

Deepesh Shah said:

I do totally agree with you, it is really frustating if you just want to upload the newly created / updated stored procedures to the live databse or any other place and you have to sit and think which one you have to upload instead just choosing by lst modified date and uplaod them.
May 12, 2005 5:39 AM
 

Javier Luna said:

I believe that any DataLayer must be a simple code block, that they allow operations against DB.

That code block would not have to know on the Business Entities. Single to specialize it is to execute the operations (Store Procedures and SQL Sentences) against the engine DB (SQL, Oracle, DB2, etc.), with which this setting.

Finally, I invite to you to download the DataLayer.Primitives Public Version.

This is very cool Data Layer :)

DataLayer.Primitives - Readme!
http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=1389

Cheers,

Javier Luna
http://guydotnetxmlwebservices.blogspot.com/
May 26, 2005 11:33 PM

Leave a Comment

(required)  
(optional)
(required)  
Add