Tag Archives: SQL Saturday

SQL Saturday 370 – Phoenix

Thank you to everyone who attended my session – Make Your DBA Happy: 5 Habits Developers Can Implement Today.  If you missed the session you can watch the pre-recorded video (from a prior SQL Saturday) here.  

The slide deck is available here.  Enjoy!

Eric Oszakiewski

Eric Oszakiewski is a professional software developer based in Scottsdale, AZ with over 36 years of IT experience, and 19 years Native American Gaming experience. He is currently working as a Sr .Net/SharePoint Development Lead for General Motors, and also as a consultant.

More Posts

Follow Me:
TwitterFacebookLinkedInGoogle PlusYouTube

SQL Saturday #279 – Phoenix

Here is the video from my SQL Saturday #279 session on developer best practices & good habits to help DBAs keep the server healthy and secure. Please excuse the fact I was dealing with a sinus & chest infection during the presentation, then halfway through the camera died & we had to switch to Lauri’s Windows Phone…such a superior product! You’ll notice halfway through the presentation the resolution changes, and I apologize. Next time I do a speaking engagement I plan to use a tripod & better camera (or her phone again!)

During the presentation a good question came up regarding the effort required to manage SQL code in a source controlled application vs. in a stored procedure or view, and how I suggested keeping the code in source control can be perceived as a pain in the butt. In no way am I indicating source control is a pain. Source control is a necessary tool in the development process, that in my opinion should be used regularly by all developers regardless of platform or language. My goal is to compare the effort required when a simple change to a data type (for example) is needed, to check the project out, hunt for every location in the code where someone has hard-coded queries or statements that need to be changed, change those queries or statements (and hope you got them all), run unit tests, build/compile your application (assuming nothing else was negatively affected), deploy to test, send to QC for testing, deal with any other “issues” they find, then check the final build back into source control and release to prod, then sit in hypercare hoping nothing else happens…or simply have the DBA look in your stored procedure or view for any changes needed and change them immediately. The end point was it’s way easier to keep these in stored procs or views, not to mention it gives a centrally managed place for your database code that encourages communication between the developer and the DBA, making the entire team more effective. Sorry for any confusion.

Anyway, here’s the link to the slide deck for following along, as well as the presentation

Eric Oszakiewski

Eric Oszakiewski is a professional software developer based in Scottsdale, AZ with over 36 years of IT experience, and 19 years Native American Gaming experience. He is currently working as a Sr .Net/SharePoint Development Lead for General Motors, and also as a consultant.

More Posts

Follow Me:
TwitterFacebookLinkedInGoogle PlusYouTube