InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comThu, 23 May 2013 14:30:46 GMT20http://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspx[quote][b]Mike Dougherty-384281 (7/14/2012)[/b][hr][quote][b]Jeff Moden (7/13/2012)[/b][hr][quote][b]Mike Dougherty-384281 (7/13/2012)[/b][hr][quote][b]Ola L Martins-329921 (7/13/2012)[/b][hr]...hence I never delete a-n-y-t-h-i-n-g from the tables. I use a switch "bit_deleted" and a view to get the not-deleted records...[/quote]consider a deleted [small]datetime: null indicates not deleted else it contains WHEN it was deleted.[/quote]Agreed. The only thing different that I do is that I use 9999-12-30 for a "non-deleted" date so that I can make the column NOT NULL and a bit easier to index. The reason I don't use 9999-12-31 is so I can support certain types of date math to do lookups on other columns (such as EndDate) and I just carry that little standard over into DateDeleted columns for consistency's sake.[/quote]I first read this as extreme sarcasm: using two arbitrary date values to "avoid null" and turn the datetime field back into the bit column Ola was using. Then I realized you would have followed-up sarcasm with a helpful suggestion for improvement.Then I considered seeing 9999-12-30 for 99% of the rows of my table and thought that would be weird and wrong. My bias for the NULL value to indicate not-deleted comes from habit - and using null for a sentinel value is not really different than 9999-12-30 to mean not-deleted. Fortunately its far enough in the future that we're not likely to accidentally cross that time (caveat: that value won't fit in a smalldatetime; smalldatetime's max value will occur during our professional careers) How does the nullability of this deletedate field affect an index? I admit having to write where clauses that test for "field is null OR field {op} value" can be tedious and redundant.Also, could you give some examples of the types of date math you do that makes 9999-12-30 a better choice for not-deleted than 9999-12-13?[/quote]Hi Mike,Sorry for the late reply. You're correct. There was no sarcasm nor irony in what I wrote. I use 9999-12-30 to indicate what you said you would normally use a NULL EndDate to indicate. Gus did a really good job of explaining the date math behind it (instead of using 9999-12-31) all to avoid the use of OR. As for SmallDateTime... I don't ever use it for a couple of reasons but the most significant of them is rounding. If you happen to send it something like...[code="sql"] SELECT CAST('2000-01-01 23:59:30' AS SMALLDATETIME) [/code]... the bloody thing rounds up to the next day. While I expect that and know that, I can count on one hand the number of developers I've ever met that actually know that. To me, it's simply worth the extra 4 bytes of width per column to implicitly avoid such problems and to have to have a double standard for an "end-of-time" date.I suppose that if I were relegated to working with SQL Express, then I might be a wee bit more conservative with how wide my date columns actually are.As a (possibly interesting) side bar, I always write my date criteria as CLOSED/OPEN (>= and <) even when writing against a DATE datatype for two reasons... I only have to be well practiced at 1 standard and it makes the code bullet proof for all of the current date/time datatypes. I have had it where someone decided they made a mistake and converted the data type of a DATE column to DATETIME because they suddenly found out time was important to them. When that happened, I didn't have to change a thing in the code that I had written.{EDIT/PS}[quote]Fortunately its far enough in the future that we're not likely to accidentally cross that time (caveat: that value won't fit in a smalldatetime; smalldatetime's max value will occur during our professional careers)[/quote]I agree... I'll only be 127 when 2079-05-28 occurs. :-PTue, 14 Aug 2012 22:12:50 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspx[quote][b]Ola L Martins-329921 (8/14/2012)[/b][hr]I'd like to differ on the "virtual deletion" - in my opinion - or better put - in my mind - the deleted-column (in any form) does not reflect the state of the row itself, but a status of the contained data (order, product, whatever). (Splitting ends, I know... :-))[/quote]Heh... "Splitting ends" is an understatement here. :-)Tue, 14 Aug 2012 21:32:25 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspx[quote][b]GSquared (8/6/2012)[/b][hr][quote][b]Mike Dougherty-384281 (7/14/2012)[/b][hr][quote][b]Jeff Moden (7/13/2012)[/b][hr][quote][b]Mike Dougherty-384281 (7/13/2012)[/b][hr][quote][b]Ola L Martins-329921 (7/13/2012)[/b][hr]...hence I never delete a-n-y-t-h-i-n-g from the tables. I use a switch "bit_deleted" and a view to get the not-deleted records...[/quote]consider a deleted [small]datetime: null indicates not deleted else it contains WHEN it was deleted.[/quote]Agreed. The only thing different that I do is that I use 9999-12-30 for a "non-deleted" date so that I can make the column NOT NULL and a bit easier to index. The reason I don't use 9999-12-31 is so I can support certain types of date math to do lookups on other columns (such as EndDate) and I just carry that little standard over into DateDeleted columns for consistency's sake.[/quote]...While I personally find "virtual deletion" to be a horrible, horrible solution in the vast majority of cases, having an arbitrarily late Deleted value does make sense compared to NULL, when it comes to query optimization....[/quote]I'd like to differ on the "virtual deletion" - in my opinion - or better put - in my mind - the deleted-column (in any form) does not reflect the state of the row itself, but a status of the contained data (order, product, whatever). (Splitting ends, I know... :-))Tue, 14 Aug 2012 02:50:44 GMTOla L Martins-329921http://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspx[quote][b]Ewald Cress (8/7/2012)[/b][hr][quote][b]GSquared (8/6/2012)[/b][hr]Complexities like these are one of the myriad of reasons I consider such systems horribly flawed in the vast majority of cases. They make documentation more difficult. They increase the odds of coding failure. They increase training time for new developers. The list goes on, and on, and on.[/quote]Amen to that! I thought it was odd that nobody else expressed negative opinions about the design pattern, so glad to see I have company; I agree with all your specific reasons.Not that there isn't room in certain designs for the pattern, but I have suffered through an environment where columns like EffectiveFrom, EffectiveTo and DateArchived were mandated by coding standards, even though there was no accompanying agreed standard of how one was supposed to use and interpret these, and in many cases they weren't semantically meaningful at all. People regularly screw up when querying [b]simple[/b] systems - why would they possibly fare better if you force an unnecessarily complicated design upon them?(ETA: By the way, I am referring to a transactional system here, and not a data warehouse. I have no quarrels with SCDs)[/quote]Yeah, SCDs in warehouses are a different thing. If that's what this is about, then nix my negative on it. I've just been burned too often by poorly designed and implemented virtual-delete/update OLTP databases.Tue, 07 Aug 2012 06:06:41 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspx[quote][b]GSquared (8/6/2012)[/b][hr]Complexities like these are one of the myriad of reasons I consider such systems horribly flawed in the vast majority of cases. They make documentation more difficult. They increase the odds of coding failure. They increase training time for new developers. The list goes on, and on, and on.[/quote]Amen to that! I thought it was odd that nobody else expressed negative opinions about the design pattern, so glad to see I have company; I agree with all your specific reasons.Not that there isn't room in certain designs for the pattern, but I have suffered through an environment where columns like EffectiveFrom, EffectiveTo and DateArchived were mandated by coding standards, even though there was no accompanying agreed standard of how one was supposed to use and interpret these, and in many cases they weren't semantically meaningful at all. People regularly screw up when querying [b]simple[/b] systems - why would they possibly fare better if you force an unnecessarily complicated design upon them?(ETA: By the way, I am referring to a transactional system here, and not a data warehouse. I have no quarrels with SCDs)Tue, 07 Aug 2012 00:58:00 GMTEwald Cresshttp://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspxOn the date-math item, it's not so applicable to a delete date, but it is to others.Since you may have to declare a non-null "end date" that has to be greater-than any possible "DateColumn" value, in order to take into account the ones that are "at the end of time", and you can't assign a value of 1 Jan 10,000 (it only goes up to 31 Dec 9999) without getting an error, you need to leave one for padding.Say you have a table with "ValidFrom" and "ValidTo" columns, for example. If you don't want an end-date on a row, you put in 31 Dec 9999, because that's the max allowed value for DateTime datatype.Then you want to query everything that's valid, so you query "Where ValidFrom > @InputParam1 and ValidTo < @InputParam2", well, you can't do that now, since you'd have to assign 1 Jan 10,000 to @InputParam2. So put the "end of time" value as 30 Dec, and assign the parameter 31 Dec, both in 9999, and now your query will work without an error message.Make sense?(Complexities like these are one of the myriad of reasons I consider such systems horribly flawed in the vast majority of cases. They make documentation more difficult. They increase the odds of coding failure. They increase training time for new developers. The list goes on, and on, and on.)Mon, 06 Aug 2012 12:27:22 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspx[quote][b]Mike Dougherty-384281 (7/14/2012)[/b][hr][quote][b]Jeff Moden (7/13/2012)[/b][hr][quote][b]Mike Dougherty-384281 (7/13/2012)[/b][hr][quote][b]Ola L Martins-329921 (7/13/2012)[/b][hr]...hence I never delete a-n-y-t-h-i-n-g from the tables. I use a switch "bit_deleted" and a view to get the not-deleted records...[/quote]consider a deleted [small]datetime: null indicates not deleted else it contains WHEN it was deleted.[/quote]Agreed. The only thing different that I do is that I use 9999-12-30 for a "non-deleted" date so that I can make the column NOT NULL and a bit easier to index. The reason I don't use 9999-12-31 is so I can support certain types of date math to do lookups on other columns (such as EndDate) and I just carry that little standard over into DateDeleted columns for consistency's sake.[/quote]I first read this as extreme sarcasm: using two arbitrary date values to "avoid null" and turn the datetime field back into the bit column Ola was using. Then I realized you would have followed-up sarcasm with a helpful suggestion for improvement.Then I considered seeing 9999-12-30 for 99% of the rows of my table and thought that would be weird and wrong. My bias for the NULL value to indicate not-deleted comes from habit - and using null for a sentinel value is not really different than 9999-12-30 to mean not-deleted. Fortunately its far enough in the future that we're not likely to accidentally cross that time (caveat: that value won't fit in a smalldatetime; smalldatetime's max value will occur during our professional careers) How does the nullability of this deletedate field affect an index? I admit having to write where clauses that test for "field is null OR field {op} value" can be tedious and redundant.Also, could you give some examples of the types of date math you do that makes 9999-12-30 a better choice for not-deleted than 9999-12-13?[/quote]While I personally find "virtual deletion" to be a horrible, horrible solution in the vast majority of cases, having an arbitrarily late Deleted value does make sense compared to NULL, when it comes to query optimization.It allows you to avoid OR statements in your Where clauses, which makes for better chances for an index seek instead of a scan.[code="sql"]SELECT *FROM dbo.MyTableWHERE Deleted > @MyInputParam;[/code]will likely seek better than[code="sql"]SELECT *FROM dbo.MyTableWHERE Deleted > @MyInputParam OR Deleted IS NULL;[/code]Slightly easier to write (one less line of code, really), but can make a difference in execution plans that may actually matter.Of course, it'll mess with the selectivity/cardinality, if a huge percentage of your rows are "undeleted", which may just trash every query in your database all by itself, in terms of performance.Mon, 06 Aug 2012 12:20:39 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspx[quote][b]john.moreno (8/6/2012)[/b][hr][quote]For instance, I recently said at my workplace that a database backup created on one version of SQL Server could not be restored onto a different version of SQL Server.[/quote]Not to get too far afield of your main point, but could you clarify this? As far as I know you can't restore to a [b]prior[/b] version of sql server, but can to a subsequent version. If you can restore to a prior version, I'd love to hear that I was wrong (and how to do so).[/quote]Yes, you are right. I had said that a backup of 2005 could not be restored to 2008. I was wrong, of course.Mon, 06 Aug 2012 11:39:10 GMThakim.alihttp://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspx[quote][b]GSquared (8/6/2012)[/b]Oh, and a very common mistake on this is to set a database from a later version, into a prior compatibility mode, then back it up and try to restore it on a prior version of SQL Server. Doesn't work. Can't set a database to Compat 80, from SQL 2008, and restore it on SQL 2000. Doesn't work. For relatively obvious reasons, lots of people think it will, and can't figure out why it doesn't work.[/quote]I fell into this trap too...Mon, 06 Aug 2012 11:38:04 GMThakim.alihttp://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspx[quote][b]john.moreno (8/6/2012)[/b][hr][quote]For instance, I recently said at my workplace that a database backup created on one version of SQL Server could not be restored onto a different version of SQL Server.[/quote]Not to get too far afield of your main point, but could you clarify this? As far as I know you can't restore to a [b]prior[/b] version of sql server, but can to a subsequent version. If you can restore to a prior version, I'd love to hear that I was wrong (and how to do so).[/quote]You can restore to a later version, within limits, but not to an earlier version. That's correct.General rule of thumb is 2 versions earlier is okay.Oh, and a very common mistake on this is to set a database from a later version, into a prior compatibility mode, then back it up and try to restore it on a prior version of SQL Server. Doesn't work. Can't set a database to Compat 80, from SQL 2008, and restore it on SQL 2000. Doesn't work. For relatively obvious reasons, lots of people think it will, and can't figure out why it doesn't work.Mon, 06 Aug 2012 11:16:28 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspx[quote]For instance, I recently said at my workplace that a database backup created on one version of SQL Server could not be restored onto a different version of SQL Server.[/quote]Not to get too far afield of your main point, but could you clarify this? As far as I know you can't restore to a [b]prior[/b] version of sql server, but can to a subsequent version. If you can restore to a prior version, I'd love to hear that I was wrong (and how to do so).Mon, 06 Aug 2012 10:32:35 GMTjohn.morenohttp://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspx[quote][b]Mike Dougherty-384281 (7/14/2012)[/b][hr][quote][b]Jeff Moden (7/13/2012)[/b][hr][quote][b]Mike Dougherty-384281 (7/13/2012)[/b][hr][quote][b]Ola L Martins-329921 (7/13/2012)[/b][hr]...hence I never delete a-n-y-t-h-i-n-g from the tables. I use a switch "bit_deleted" and a view to get the not-deleted records...[/quote]consider a deleted [small]datetime: null indicates not deleted else it contains WHEN it was deleted.[/quote]Agreed. The only thing different that I do is that I use 9999-12-30 for a "non-deleted" date so that I can make the column NOT NULL and a bit easier to index. The reason I don't use 9999-12-31 is so I can support certain types of date math to do lookups on other columns (such as EndDate) and I just carry that little standard over into DateDeleted columns for consistency's sake.[/quote]I first read this as extreme sarcasm: using two arbitrary date values to "avoid null" and turn the datetime field back into the bit column Ola was using. Then I realized you would have followed-up sarcasm with a helpful suggestion for improvement.Then I considered seeing 9999-12-30 for 99% of the rows of my table and thought that would be weird and wrong. My bias for the NULL value to indicate not-deleted comes from habit - and using null for a sentinel value is not really different than 9999-12-30 to mean not-deleted. Fortunately its far enough in the future that we're not likely to accidentally cross that time (caveat: that value won't fit in a smalldatetime; smalldatetime's max value will occur during our professional careers) How does the nullability of this deletedate field affect an index? I admit having to write where clauses that test for "field is null OR field {op} value" can be tedious and redundant.Also, could you give some examples of the types of date math you do that makes 9999-12-30 a better choice for not-deleted than 9999-12-13?[/quote]We're sliding off topic here, but anyways...I personally would never use NULL as an indicator - actually I prefer not to have NULL anywhere in my tables.Yeah - it's good to now when it was deleted but for that purposes I use a custom log.Ok, considered, and dismissed. Hehe... :smooooth:Sat, 14 Jul 2012 14:37:24 GMTOla L Martins-329921http://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspx[quote][b]Jeff Moden (7/13/2012)[/b][hr][quote][b]Mike Dougherty-384281 (7/13/2012)[/b][hr][quote][b]Ola L Martins-329921 (7/13/2012)[/b][hr]...hence I never delete a-n-y-t-h-i-n-g from the tables. I use a switch "bit_deleted" and a view to get the not-deleted records...[/quote]consider a deleted [small]datetime: null indicates not deleted else it contains WHEN it was deleted.[/quote]Agreed. The only thing different that I do is that I use 9999-12-30 for a "non-deleted" date so that I can make the column NOT NULL and a bit easier to index. The reason I don't use 9999-12-31 is so I can support certain types of date math to do lookups on other columns (such as EndDate) and I just carry that little standard over into DateDeleted columns for consistency's sake.[/quote]I first read this as extreme sarcasm: using two arbitrary date values to "avoid null" and turn the datetime field back into the bit column Ola was using. Then I realized you would have followed-up sarcasm with a helpful suggestion for improvement.Then I considered seeing 9999-12-30 for 99% of the rows of my table and thought that would be weird and wrong. My bias for the NULL value to indicate not-deleted comes from habit - and using null for a sentinel value is not really different than 9999-12-30 to mean not-deleted. Fortunately its far enough in the future that we're not likely to accidentally cross that time (caveat: that value won't fit in a smalldatetime; smalldatetime's max value will occur during our professional careers) How does the nullability of this deletedate field affect an index? I admit having to write where clauses that test for "field is null OR field {op} value" can be tedious and redundant.Also, could you give some examples of the types of date math you do that makes 9999-12-30 a better choice for not-deleted than 9999-12-13?Sat, 14 Jul 2012 10:22:32 GMTMike Dougherty-384281http://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspx[quote][b]Mike Dougherty-384281 (7/13/2012)[/b][hr][quote][b]Ola L Martins-329921 (7/13/2012)[/b][hr]...hence I never delete a-n-y-t-h-i-n-g from the tables. I use a switch "bit_deleted" and a view to get the not-deleted records...[/quote]consider a deleted [small]datetime: null indicates not deleted else it contains WHEN it was deleted.[/quote]Agreed. The only thing different that I do is that I use 9999-12-30 for a "non-deleted" date so that I can make the column NOT NULL and a bit easier to index. The reason I don't use 9999-12-31 is so I can support certain types of date math to do lookups on other columns (such as EndDate) and I just carry that little standard over into DateDeleted columns for consistency's sake.Fri, 13 Jul 2012 18:56:37 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspx[quote][b]Ola L Martins-329921 (7/13/2012)[/b][hr]...hence I never delete a-n-y-t-h-i-n-g from the tables. I use a switch "bit_deleted" and a view to get the not-deleted records...[/quote]consider a deleted [small]datetime: null indicates not deleted else it contains WHEN it was deleted.Fri, 13 Jul 2012 15:00:29 GMTMike Dougherty-384281http://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspxMany times in life, I have found, it's not really about being right or wrong...it's about being at a point in life of having the guts (or balls) to get off the dime and just make a decision. Many times indecision, and second-guessing yourself, can be downright paralyzing, and sometimes ultimately, can have tragic results. Sometimes, you just gotta get off the pot and go "all in" and go with what you believe, right or wrong. :-DFri, 13 Jul 2012 11:23:15 GMTTravisDBAhttp://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspx[quote][b]david.wright-948385 (7/12/2012)[/b][hr][quote][b]djackson 22568 (7/12/2012)[/b][hr]....A paranoid dba is a good dba :-)[/quote]...hence I never delete a-n-y-t-h-i-n-g from the tables. I use a switch "bit_deleted" and a view to get the not-deleted records...(Oh - please leave me alone prefixing a fieldname - the boolean-values are the only one I do it w/ - as a marker and reminder what this field is about...)and[quote][b]Frank W Fulton Jr (7/12/2012)[/b][hr]I was once told "if you are not making mistakes, chances are you aren't doing anything".Every one makes mistakes, the important thing is to learn from them[/quote]Well - I can agree w/ the first sentence - but mistakes are there for us to recognize when we make them again... ;-)...like the guy w/ the faulty if-statements.Fri, 13 Jul 2012 01:42:56 GMTOla L Martins-329921http://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspxI was once told "if you are not making mistakes, chances are you aren't doing anything".Every one makes mistakes, the important thing is to learn from themThu, 12 Jul 2012 20:04:41 GMTFrank W Fulton Jrhttp://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspx[quote][b]djackson 22568 (7/12/2012)[/b][hr][quote][b]Antares686 (7/11/2012)[/b][hr]The same goes with arguements with the wife, she get's very mad with me becuase I won't just accept she is right if I feel she is incorrect or proof needs to be given. Those moments are the worst, she goes on how I am arguementative and always have to be right and I have to rein her in by reminding her arguements require more thsan one person, and two no one should ever just conceed on face value unless they know the other person is right.[/quote]Exactly! I hear this all the time as well. My previous point about all of us having an opinion and thinking we are right ties in with this. Show me proof and I will gladly change my opinion. I fondly remember a situation where I refactored some code and reduced it by about 2/3rds. People screamed "this isn't right" because my code was much cleaner, shorter and in the end corrected mistakes they had made. I had to prove to them my code was correct, but I had to first spend a huge amount of time convincing them it was worth looking at.[/quote]Been there done that, took over an app with something like 57000 line of code, rewrote it into something like 18000 lines. Majority was simple find and replace.On that note my favorite Bill Gates quote [quote]Measuring programming progress by lines of code is like measuring aircraft building progress by weight.[/quote]Thu, 12 Jul 2012 10:51:46 GMTAntares686http://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspx[quote][b]david.wright-948385 (7/12/2012)[/b][hr][quote][b]djackson 22568 (7/12/2012)[/b][hr]I have been taught to always write a select before a delete. Confirm the records, then use that code to write the update/delete. [/quote]I'm not saying you're wrong (obviously!) but I prefer: [code="sql"]begin transaction; delete tablename output deleted.* [into anothertable] where <condition>; [select * from anothertable;]rollback;[/code]Then the only thing you have to change is the "commit" and (with the 'into' clause) you get a 'hard' copy of the stuff you just deleted by mistake.A paranoid dba is a good dba :-)[/quote]Proving once again that even good ideas can be improved!Great script, David.DaveThu, 12 Jul 2012 10:37:12 GMTdjackson 22568http://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspx[quote][b]djackson 22568 (7/12/2012)[/b][hr]I have been taught to always write a select before a delete. Confirm the records, then use that code to write the update/delete. [/quote]I'm not saying you're wrong (obviously!) but I prefer: [code="sql"]begin transaction; delete tablename output deleted.* [into anothertable] where <condition>; [select * from anothertable;]rollback;[/code]Then the only thing you have to change is the "commit" and (with the 'into' clause) you get a 'hard' copy of the stuff you just deleted by mistake.A paranoid dba is a good dba :-)Thu, 12 Jul 2012 08:08:38 GMTdavid.wright-948385http://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspx[quote][b]SQLBill (7/11/2012)[/b][hr]This is like writing...you should never edit your own writing. We all 'know' what we intended to do or write so we can't see our mistakes. Whenever I write a large script, I always have someone review it for me. I'd rather I was found to be wrong before something bad happens than finding out later (missing WHERE clause on a Delete or Update anyone????).-SQLBill[/quote]Off topic, but important enough to comment on:I have been taught to always write a select before a delete. Confirm the records, then use that code to write the update/delete. The issue there isn't being wrong, it is being uneducated or stupid. Uneducated the first time you make the mistake, or if nobody gave you advice on how to do it more safely. Stupid when you continue to do the same thing despite being offered good advice on how to prevent it. I believe I posted here once about a guy that wrote all his C++ if statements like;If (a = 5)instead ofIf (a == 5)He couldn't figure out why the code always failed. We explained to him about the double equals yet he made this same mistake hundreds of times! I gave him an easy solution:If (5 == a)He refused to follow it as he viewed it as hard to understand! (Insert profane descriptive word or phrase here) I explained how the compiler would catch the mistake he made if he placed the constant first, but he simply wouldn't listen. I bet he is still making this same mistake because he is too obstinate (stupid) to follow good coding advice.There are a huge number of people who have made the same mistakes we make - failure to learn from their errors is just dumb.DaveThu, 12 Jul 2012 07:35:16 GMTdjackson 22568http://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspx[quote][b]Antares686 (7/11/2012)[/b][hr]The same goes with arguements with the wife, she get's very mad with me becuase I won't just accept she is right if I feel she is incorrect or proof needs to be given. Those moments are the worst, she goes on how I am arguementative and always have to be right and I have to rein her in by reminding her arguements require more thsan one person, and two no one should ever just conceed on face value unless they know the other person is right.[/quote]Exactly! I hear this all the time as well. My previous point about all of us having an opinion and thinking we are right ties in with this. Show me proof and I will gladly change my opinion. I fondly remember a situation where I refactored some code and reduced it by about 2/3rds. People screamed "this isn't right" because my code was much cleaner, shorter and in the end corrected mistakes they had made. I had to prove to them my code was correct, but I had to first spend a huge amount of time convincing them it was worth looking at.Another event I remember is a coworker who rarely made any kind of error telling me I was wrong. She was kind of shy, and didn't like doing this with anyone. My response was "well I am sure I have it right, but since you think otherwise, I must be wrong". She was shocked that I took her opinion so highly. Oh, she was right!If more people would handle mistakes without the criticism, we would all be better off.If supervisors and managers would handle the staff that consistently makes the same mistakes, maybe people wouldn't feel the need to [b][i]be[/i][/b] critical of repeated errors.DaveThu, 12 Jul 2012 07:22:33 GMTdjackson 22568http://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspx[quote][b]WolforthJ (7/12/2012)[/b]I think it is more important to discuss how to deal with problem...[/quote]I couldn't agree more. Trouble is, if you can't fix it, you're faced with moving (plenty more rivers around!) or in the worst case suffering psychological damage.Thu, 12 Jul 2012 06:36:39 GMTdavid.wright-948385http://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspx[quote]Continuing the evolution metaphor, if you can't treat your current coworkers as reliable members of your tribe you should probably consider some new coworkers.[/quote]I usually don't respond to comments like this, because they are true, there is no argument, really. However, it is also true that there are a lot of dysfunctional workplaces out there. I read statistic a long ago, so apologies for inaccuracy, but there are something like 20% or more of employees who are actively working to sabotage their company. That would include hassling other employees and trying to make someone else look bad for some personal reason. If you accept the bell curve theory, there have to be some incompetent people working just about everywhere. Very few management teams acknowledge these things and often it is management that is enabling or instigated the dysfunction. I live in a small market. There are some good jobs here, but people hang on to them. I can't just move every 4 years like I did when I lived in a metro area. I love my house on the river (until the river decided to come to my house last month, but that's another story) so I'm not moving just to get a slightly better job. I think it is more important to discuss how to deal with problem people rather presenting the "you should move" solution for everything.Thu, 12 Jul 2012 06:27:29 GMTWolforthJhttp://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspx[quote][b]SQLRNNR (7/11/2012)[/b][hr][quote][b]Michael Lysons (7/11/2012)[/b][hr]Sadly, I think part of the problem is another human trait; the ridicule of those who are wrong.It's even evident on this site. Just look at a whole host of QotD posts, and you'll see stuff like "Good, back to basics question" and "I can't believe x% got this wrong" - all subtle little digs at those who may be wrong....[/quote]I hadn't thought of those comments as digs on those who are wrong. Usually more to the point of the questioner and as a compliment to him/her for reminding all of things of that nature. Though it is good to see these points of view. I will certainly try harder to make the comments seem less of a dig.[/quote]I see "good back to basics question" as a compliment. With the x% comment, I agree: it could be simple lack of thought, but it could be an attempt to display superiority or "win points" at the expense of others. There are various psychological theories associated the attempts of the insecure to feel secure by attacking others. Taken further than in this (x%) example, "bullying" may be one that applies.Thu, 12 Jul 2012 02:49:07 GMTdavid.wright-948385http://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspx[quote][b]Michael Lysons (7/11/2012)[/b][hr]Sadly, I think part of the problem is another human trait; the ridicule of those who are wrong.It's even evident on this site. Just look at a whole host of QotD posts, and you'll see stuff like "Good, back to basics question" and "I can't believe x% got this wrong" - all subtle little digs at those who may be wrong....[/quote]I hadn't thought of those comments as digs on those who are wrong. Usually more to the point of the questioner and as a compliment to him/her for reminding all of things of that nature. Though it is good to see these points of view. I will certainly try harder to make the comments seem less of a dig.Wed, 11 Jul 2012 16:51:15 GMTSQLRNNRhttp://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspxThis is like writing...you should never edit your own writing. We all 'know' what we intended to do or write so we can't see our mistakes. Whenever I write a large script, I always have someone review it for me. I'd rather I was found to be wrong before something bad happens than finding out later (missing WHERE clause on a Delete or Update anyone????).-SQLBillWed, 11 Jul 2012 14:18:12 GMTSQLBillhttp://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspxAnother reason to accept being proven wrong is that it shows someone else is aware enough to see/understand your mistake. As long as they've "got your back" you can proceed more confidently than if you must treat every move as life threatening ( Hakim's "... you died" )Continuing the evolution metaphor, if you can't treat your current coworkers as reliable members of your tribe you should probably consider some new coworkers.Wed, 11 Jul 2012 14:17:49 GMTMike Dougherty-384281http://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspxI'm never wrong. I thought I was wrong once, but I was mistaken. I've heard this put many ways, but this editorial was one of the best. My degree is in computer SCIENCE. If we are truly scientists, then we should act like that. We should not act like the engineers at Morton-Thiokol and "take off off our engineer hats and put on our marketing hats" and make a decision that results in a Space Shuttle blowing up. We should act like the older scientist who, when his Noble prize winning idea is proven to be wrong, he applauds it. "Wrong" is really the wrong word. It should be "out of date" or "new evidence has shown" or "here is an alternative worth considering". I'm not trying to sugar coat, I'm saying we are wrong when we don't have the right data or just missed something, like I said, "mistaken".Wed, 11 Jul 2012 13:05:10 GMTWolforthJhttp://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspxAnd here I thought I was the only one who didn't mind being wrong about something! Guess I was wrong about that. ;-)Wed, 11 Jul 2012 09:58:50 GMTStephanie J Brownhttp://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspx[quote]Hence, crazy as it sounds, I look forward to being proven wrong.[/quote]Not sure I would agree with the wording...[quote]When that happens, I accept it and embrace it, and I am better off for it. If you show me I am wrong, I will thank you for it.[/quote] I have felt this way for a long time. Most people get upset when you discuss things like this. However we all are wrong quite frequently.One analogy I use is about opinions. People frequently acuse others of being opinionated. Well of course people are opinionated! We ALL ARE!!! We also always believe our opinions are correct.Once we [b]know[/b] that our opinions are incorrect, we change them! The thing is that humans seem reluctant to accept factual evidence easily. It is probably due to things like how our media outright lies about things to sway public opinion - which causes people to fall into two groups. The first is the majority of people who believe everything they hear from their favorite source, regardless of how ridiculous it is (see recent jobs reports that the liberal media claims is evidence our economy is sound as just one example). The second is those people who hear things, but actually try to determine for themselves whether there is truth behind it. I submit most of the people in this group fall into the second group.DaveWed, 11 Jul 2012 09:26:40 GMTdjackson 22568http://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspx[quote][b]david.wright-948385 (7/11/2012)[/b][hr] But there is another side to this coin: when [b]someone else[/b] is wrong, we need to treat that in a helpful light too. It's so much easier to accept a lesson learned if it is learned in a helpful atmosphere: without risk of criticism, disdain or even ridicule. In this way we can encourage others to learn from their mistakes and help our situation become one where everyone can accept these 'learning opportunities" (our own, or others') rather than deny them. [/quote]So very true. I don't learn very well when someone is screaming at me or humiliating me. So, how could I expect someone else to learn that way?Wed, 11 Jul 2012 08:12:26 GMTmarcia.j.wilsonhttp://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspxI see that there is no harm in being wrong. However, just becuase someone say I am wrong doesn't mean I will accept it at face value. I will say let me check on that and confirm what they say is correct or not. I will willing accept it if they are or if it is questionable as query performance can sometimes be in SQL Server I will test it several ways and conceed if it is proven. I have no trouble being wrong and don't mind being called on it in an open form. The same goes with arguements with the wife, she get's very mad with me becuase I won't just accept she is right if I feel she is incorrect or proof needs to be given. Those moments are the worst, she goes on how I am arguementative and always have to be right and I have to rein her in by reminding her arguements require more thsan one person, and two no one should ever just conceed on face value unless they know the other person is right.Wed, 11 Jul 2012 08:11:42 GMTAntares686http://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspxTerriffic point! I can hardly imagine how much a team could learn if everyone on it had that same idea.Wed, 11 Jul 2012 08:06:53 GMTDavid Lesterhttp://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspx[quote][b]Ewald Cress (7/11/2012)[/b][hr]Excellent post, and one that really struck a chord with me. I, too, take delight in being wrong, for pretty much the reasons that Hakim outlined. But there is another side to it. If you're known to admit when you've been wrong, and willing to state "This is my current opinion, as opposed to a firm belief I won't budge from," people may well end up valuing your input more. Even in brute survival terms, that's a win.[/quote]Ewald, I am sitting here laughing because I said the same thing "[i]really struck a chord with me.....[/i]" , when I forwarded this editorial to one of my team members. I am a Type A personality and I will readily admit that I don't like being wrong, both personally and professionally, however Hakim makes very valid points and quite honestly made me look at how I dealt with being wrong.Recently before I read this article, I used this principle but applied it to making mistakes. It is okay to make mistakes, because it creates an opportunity to learn something you might not know or possibly a different facet of something you already did. Hakim, thanks for the editorial; good read.Wed, 11 Jul 2012 07:38:04 GMTChris Revill-286168http://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspxWe learn from our mistakes; some of the dumbest people I know have never been wrong.Wed, 11 Jul 2012 07:06:03 GMTgone2mt-908760http://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspxThere are plenty of things I'd love to be proven wrong about....Wed, 11 Jul 2012 06:51:19 GMTjay-hhttp://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspxExcellent post, and one that really struck a chord with me. I, too, take delight in being wrong, for pretty much the reasons that Hakim outlined. But there is another side to it. If you're known to admit when you've been wrong, and willing to state "This is my current opinion, as opposed to a firm belief I won't budge from," people may well end up valuing your input more. Even in brute survival terms, that's a win.Wed, 11 Jul 2012 05:39:50 GMTEwald Cresshttp://www.sqlservercentral.com/Forums/Topic1328048-263-1.aspx[quote][b]david.wright-948385 (7/11/2012)[/b][hr]But there is another side to this coin: when [b]someone else[/b] is wrong, we need to treat that in a helpful light too. It's so much easier to accept a lesson learned if it is learned in a helpful atmosphere: without risk of criticism, disdain or even ridicule.[/quote]Great point, thank you for raising that, I had not so much considered that particular perspective.Wed, 11 Jul 2012 05:26:23 GMThakim.ali