Re: Source control of DB scripts
Greg, An approach that worked well in the past for me was: * No permission to execute DDL statements on staging / dev databases given to the developers. They still have full access to their local copies. * All database updates (tables, SPs, population scripts etc) are to be checked into source control system * All above scripts are to be re-runnable (for example a new field is to be added to table, the ALTER statement is condition with an IF to check if the field is not already in there) * The continuos integration server periodically (or on request) executes all current SQL scripts as found in repository however this is defined (could be a TXT file, a DB table, version numbering system etc) recreating the stored procedures and views and tables etc This way all updates are kept in repository and are 'scripted' in a way so the DB deployment is testable and manageable. j. On 31 May 2010 12:56, Alan Heywood a...@heywood.id.au wrote: Hi Greg, I use MigratorDotNet http://code.google.com/p/migratordotnet/ to address this issue. Migrator allows me to define incremental changes to the database using code, which is then checked into source control along with everything else. We have a Continuous Integration setup, and when a build is triggered the following occurs: 1. Code is compiled 2. MigratorDotNet is called, passing in a reference to the xxx.data.dll from our project. 3. Migrator uses reflection to find a list of 'migrations'. Version number is compared to the current one stored in a table in the database. If there are new migrations to be run then they are executed on the database. Using this approach you can create tables, define foreign key constraints, add new colums etc. You can also execute arbitrary SQL statements. This means that you can also add or modify data as part of a migration. Works really well for me, particularly since I would otherwise be manually attempting to keep 10 databases in sync. Alan On 31 May 2010 11:14, Greg Keogh g...@mira.net wrote: Folks, I’m sure we’ve all had problems where multiple developers change SQL Server scripts and they get out of whack and waste time with stupid errors. I’m starting a fresh app and I thought I’d experiment with keeping scripts in SVN. It just means that we have to remember to always save a script to the source controlled file whenever it’s changed. Because scripts aren’t compiled source code, there is still the risk of human error in not pushing any updated script files into the DB. I was thinking of concocting a utility which automatically pushed changed scripts into the DB, but before I start fiddling I thought I’d ask about this subject in general first. Are there others out there who source control their DB scripts and have techniques for reducing human error? Or perhaps there are better techniques that I’ve completely overlooked. Greg
Ignoring excpetions in catch
I thought only the beginner programmers or programmers without any
pride in their work or self discipline would write code like this:
try
{
//some code goes here
}
catch
{
//No code here just business as usual, do nothing about the exceptions!
}
but maybe I am wrong, this http://support.microsoft.com/kb/319465 was
unexpected!
in the code in the above link are there any reasons for
1)Checking the type, or more generally first checking that at least
the minimum requirements of an operations will be satisfied before
using a sledge hammer?
2)Using some other (better) code e.g. reflection etc. would be
definitely more preferable to ignoring excpetion?
3)Any other suggestions?
Regards
Arjang
Re: Ignoring excpetions in catch
Yep, just change the cast from:
ctlMDI = (MdiClient) ctl;
to
ctlMDI = ctl as MdiClient;
then check for null.
But having said that, I'm sure all of the code on MSDN/Microsoft web sites
are not production ready.. The code is only to communicate ideas..
Just my 2c...
Ed.
On Tue, Jun 1, 2010 at 10:38 AM, Arjang Assadi arjang.ass...@gmail.comwrote:
I thought only the beginner programmers or programmers without any
pride in their work or self discipline would write code like this:
try
{
//some code goes here
}
catch
{
//No code here just business as usual, do nothing about the exceptions!
}
but maybe I am wrong, this http://support.microsoft.com/kb/319465 was
unexpected!
in the code in the above link are there any reasons for
1)Checking the type, or more generally first checking that at least
the minimum requirements of an operations will be satisfied before
using a sledge hammer?
2)Using some other (better) code e.g. reflection etc. would be
definitely more preferable to ignoring excpetion?
3)Any other suggestions?
Regards
Arjang
--
Eddie de Bear
Mob: 0417066315
Messenger: eddie_deb...@hotmail.com
Skype: eddiedebear
Re: Ignoring excpetions in catch
Your example is a catch all which is bad practice.
The example in the MS article catches a specific exception. This is not the
same thing. There can be circumstances where you want to catch a specific
exception and do nothing about it.
On 1 June 2010 10:38, Arjang Assadi arjang.ass...@gmail.com wrote:
I thought only the beginner programmers or programmers without any
pride in their work or self discipline would write code like this:
try
{
//some code goes here
}
catch
{
//No code here just business as usual, do nothing about the exceptions!
}
but maybe I am wrong, this http://support.microsoft.com/kb/319465 was
unexpected!
in the code in the above link are there any reasons for
1)Checking the type, or more generally first checking that at least
the minimum requirements of an operations will be satisfied before
using a sledge hammer?
2)Using some other (better) code e.g. reflection etc. would be
definitely more preferable to ignoring excpetion?
3)Any other suggestions?
Regards
Arjang
Re: Source control of DB scripts
Yes the directory structure looks like: - DatabaseName - Tables - StoredProcs - Views - Triggers - PopulationScripts etc A script for SP would check if SP already exists, if so, drops it and then is followed with CREATE PROCEDURE script and then permissions section. Add necessary GOes in between. With tables, it check if table already exists by selecting from INFORMATION_SCHEMA.TABLES and if not, creates it With alter table scripts for ex. adding new column, check if querying information-schema for presence of this column and if not there, creates it With population scripts, checks if data is already in table (a single representative record of the set for example) and if not, adds it. This way changes to procs for example accross different branches/streams are easily integrated. One important rule is to have strong SQL coding standard (one field per line, one table per line, one join per line etc) so the automatic merging is easily done. There is an easy way using SQL-DMO to extract all current DB objects (scripts, tables etc) from DB and create a single SQL file per each one to set up initial source control repository for example. Or alternatively VS database project can be used. These are then easily executed using command line with SQLCMD for example and can be scripted as deployment task etc. j. On 1 June 2010 10:16, Wallace Turner w.tur...@fex.com.au wrote: Could you please elaborate on * All database updates (tables, SPs, population scripts etc) are to be checked into source control system That is, do you have one txt file per stored proc and table definition? If Yes, do you simply copy the stored proc contents to a text file from VS? Wal *From:* ozdotnet-boun...@ozdotnet.com [mailto: ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Jano Petras *Sent:* Tuesday, 1 June 2010 8:15 AM *To:* ozDotNet *Subject:* Re: Source control of DB scripts Greg, An approach that worked well in the past for me was: * No permission to execute DDL statements on staging / dev databases given to the developers. They still have full access to their local copies. * All database updates (tables, SPs, population scripts etc) are to be checked into source control system * All above scripts are to be re-runnable (for example a new field is to be added to table, the ALTER statement is condition with an IF to check if the field is not already in there) * The continuos integration server periodically (or on request) executes all current SQL scripts as found in repository however this is defined (could be a TXT file, a DB table, version numbering system etc) recreating the stored procedures and views and tables etc This way all updates are kept in repository and are 'scripted' in a way so the DB deployment is testable and manageable. j. On 31 May 2010 12:56, Alan Heywood a...@heywood.id.au wrote: Hi Greg, I use MigratorDotNet http://code.google.com/p/migratordotnet/ to address this issue. Migrator allows me to define incremental changes to the database using code, which is then checked into source control along with everything else. We have a Continuous Integration setup, and when a build is triggered the following occurs: 1. Code is compiled 2. MigratorDotNet is called, passing in a reference to the xxx.data.dll from our project. 3. Migrator uses reflection to find a list of 'migrations'. Version number is compared to the current one stored in a table in the database. If there are new migrations to be run then they are executed on the database. Using this approach you can create tables, define foreign key constraints, add new colums etc. You can also execute arbitrary SQL statements. This means that you can also add or modify data as part of a migration. Works really well for me, particularly since I would otherwise be manually attempting to keep 10 databases in sync. Alan On 31 May 2010 11:14, Greg Keogh g...@mira.net wrote: Folks, I’m sure we’ve all had problems where multiple developers change SQL Server scripts and they get out of whack and waste time with stupid errors. I’m starting a fresh app and I thought I’d experiment with keeping scripts in SVN. It just means that we have to remember to always save a script to the source controlled file whenever it’s changed. Because scripts aren’t compiled source code, there is still the risk of human error in not pushing any updated script files into the DB. I was thinking of concocting a utility which automatically pushed changed scripts into the DB, but before I start fiddling I thought I’d ask about this subject in general first. Are there others out there who source control their DB scripts and have techniques for reducing human error? Or perhaps there are better techniques that I’ve completely overlooked. Greg
RE: Ignoring excpetions in catch
Hi Arjang,
In C# use the as operator and check for null; in VB use TryCast and check
for Nothing.
|-Original Message-
|From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-
|boun...@ozdotnet.com] On Behalf Of Arjang Assadi
|Sent: Tuesday, 1 June 2010 10:39 AM
|To: ozDotNet
|Subject: Ignoring excpetions in catch
|
|I thought only the beginner programmers or programmers without any
|pride in their work or self discipline would write code like this:
|
|try
|{
| //some code goes here
|}
|catch
|{
| //No code here just business as usual, do nothing about the exceptions!
|}
|
|but maybe I am wrong, this http://support.microsoft.com/kb/319465 was
|unexpected!
|in the code in the above link are there any reasons for
|1)Checking the type, or more generally first checking that at least
|the minimum requirements of an operations will be satisfied before
|using a sledge hammer?
|
|2)Using some other (better) code e.g. reflection etc. would be
|definitely more preferable to ignoring excpetion?
|
|3)Any other suggestions?
|
|Regards
|
|Arjang
Re: Ignoring excpetions in catch
Agreed, e.g. using 3rd party controls where one is at the mercy of
what ever is given is the only circumstance that comes to my mind. is
there any other circumstance that one would want to do nothing about
the exception and fix the cause rather than ignore the symptom?
Kind Regards
Arjang
On 1 June 2010 10:48, Grant Maw grant@gmail.com wrote:
Your example is a catch all which is bad practice.
The example in the MS article catches a specific exception. This is not the
same thing. There can be circumstances where you want to catch a specific
exception and do nothing about it.
On 1 June 2010 10:38, Arjang Assadi arjang.ass...@gmail.com wrote:
I thought only the beginner programmers or programmers without any
pride in their work or self discipline would write code like this:
try
{
//some code goes here
}
catch
{
//No code here just business as usual, do nothing about the exceptions!
}
but maybe I am wrong, this http://support.microsoft.com/kb/319465 was
unexpected!
in the code in the above link are there any reasons for
1)Checking the type, or more generally first checking that at least
the minimum requirements of an operations will be satisfied before
using a sledge hammer?
2)Using some other (better) code e.g. reflection etc. would be
definitely more preferable to ignoring excpetion?
3)Any other suggestions?
Regards
Arjang
Re: Ignoring excpetions in catch
Hi Bill,
Thank you for your reply. I knew that, but the question is the
practice of ignoring excpetions in catch.
Using is and as is 1% improvement over a ignoring the
exception in that example by any means, that was also suggested by
Eddie. But why or when would one ignore the specific exception when it
could have been preventet and ignore it instead?
Regards
Arjang
On 1 June 2010 10:58, Bill McCarthy b...@totalenviro.com wrote:
Hi Arjang,
In C# use the as operator and check for null; in VB use TryCast and check
for Nothing.
|-Original Message-
|From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-
|boun...@ozdotnet.com] On Behalf Of Arjang Assadi
|Sent: Tuesday, 1 June 2010 10:39 AM
|To: ozDotNet
|Subject: Ignoring excpetions in catch
|
|I thought only the beginner programmers or programmers without any
|pride in their work or self discipline would write code like this:
|
|try
|{
| //some code goes here
|}
|catch
|{
| //No code here just business as usual, do nothing about the exceptions!
|}
|
|but maybe I am wrong, this http://support.microsoft.com/kb/319465 was
|unexpected!
|in the code in the above link are there any reasons for
|1)Checking the type, or more generally first checking that at least
|the minimum requirements of an operations will be satisfied before
|using a sledge hammer?
|
|2)Using some other (better) code e.g. reflection etc. would be
|definitely more preferable to ignoring excpetion?
|
|3)Any other suggestions?
|
|Regards
|
|Arjang
RE: Ignoring excpetions in catch
I wouldn't take that sample code seriously, I guess it's old. As the others
said, in that case a cast as or try would be more appropriate. The Framework
Design Guidelines http://msdn.microsoft.com/en-us/library/ms229042.aspx
(BOOK
http://www.amazon.com/Framework-Design-Guidelines-Conventions-Libraries/dp/
0321246756 ) covers all of these sorts of issues nicely, especially about
what is exceptional or not, and that sample is not exceptional.
A ramble for newer coders here ... I fell for the trap in the my earlier
.NET coding years of over-catching. I think a lot of people had to get out
of the habit of swallowing exceptions. I've recently been working on app
code I wrote over the last several years, and I have been slowly removing
hundreds and hundreds of lines of try-catch blocks. I can see now that most
of them do nothing but clutter up the code. In my old UI code I keep finding
stuff like this skeleton:
try
{
dataSource = DataLayer.GetSomething();
}
Catch (Exception ex)
{
MessageBox.Show(Something rotten happened. + ex.ToString());
}
It's completely useless, as the method call is not supposed to fail, and if
it does fail then something is so very stuffed up that the app should crash
and stop anyway. I remove all the obviously useless try-catch blocks as I
go.
You should never try-catch unless you know specifically what you're going to
catch and you know what to do with it.
Greg
Ps. Thanks for the replies about source control of DB scripts. We'll be
discussing this over the coming days.
ASP.NET MAC Validation issue
Hi all, I'm receiving a http web exception Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that machineKey configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster. I've added a machineKey to my web.config under the system.web, which defines a validation key and algorithm. Only it's still coming up with the error still. Has anyone else had any experience with this error and can point me in the right direction? Cheers, Tiang
Re: ASP.NET MAC Validation issue
If you haven't already see http://stackoverflow.com/questions/121579 for some additional things to look at relating to this error. On Tue, Jun 1, 2010 at 11:42 AM, Tiang Cheng tiang.ch...@staff.iinet.net.au wrote: Hi all, I’m receiving a http web exception “Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that machineKey
RE: This can't be right ...
But first, time to stock up on male libido supplements... ;-) Dylan. From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Mitch Denny Sent: Tuesday, 1 June 2010 12:29 PM To: ozDotNet Subject: RE: This can't be right ... Hi guys, Thanks for pointing this out. We are aware of it and are addressing it. Regards Mitch Denny Readify | Chief Technology Officer Suite 408 Life.Lab Building | 198 Harbour Esplanade | Docklands | VIC 3008 | Australia M: +61 414 610 141 | E: mitch.de...@readify.netmailto:mitch.de...@readify.net | W: www.readify.nethttp://www.readify.net/ [cid:124581203@01062010-1735]http://www.microsoft.com/australia/remix/default.aspx The content of this e-mail, including any attachments is a confidential communication between Readify Pty Ltd and the intended addressee and is for the sole use of that intended addressee. If you are not the intended addressee, any use, interference with, disclosure or copying of this material is unauthorized and prohibited. If you have received this e-mail in error please contact the sender immediately and then delete the message and any attachment(s). From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Ian Thomas Sent: Thursday, 20 May 2010 5:38 PM To: 'ozDotNet' Subject: RE: This can't be right ... Very strange! The URLs match my worst spam (excluding ausDotNet of course). Have you done a whois lookup? Ian Thomas Victoria Park, Western Australia From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Grant Maw Sent: Thursday, 20 May 2010 3:19 PM To: ozDotNet Subject: This can't be right ... Stumbled on this today whilst looking for something else : http://www.tfsnow.com/ Looks like a Readify site. Now take a look at the tesimonials. Surely not. - To find out more about the Sunshine Coast Council, visit your local council office at Caloundra, Maroochydore, Nambour or Tewantin. Or, if you prefer, visit us on line at www.sunshinecoast.qld.gov.au This email, together with any attachments, is intended for the named recipient(s) only. Any form of review, disclosure, modification, distribution and or publication of this email message is prohibited without the express permission of the author. Please notify the sender immediately if you have received this email by mistake and delete it from your system. Unless otherwise stated, this email represents only the views of the sender and not the views of the Sunshine Coast Regional Council. maile 3_1_0 inline: image001.pnginline: image002.png
