Viewing 15 posts - 58,786 through 58,800 (of 59,063 total)
I'd have to say the data in the Birthdate column was not a valid date or date format. NULL is not a valid date during conversions.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2005 at 10:56 pm
>Say to give me all rows with a 'timestamp' column greater than a specific value?<
Yes. The datatype is varbinary and you can find the last timestamp for the entire DB...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2005 at 10:52 pm
Since you're the only one using it, change the Password on the "SA" account and go for it.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 3, 2005 at 11:30 am
Better late than never... It was the answer I was looking for...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 3, 2005 at 12:03 am
The problem is that, whatever value you are trying to update with, already exists in the Primary Key. You cannot have dupes in the Primary Key (sorry if that's so...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2005 at 10:20 pm
I know it's been a while but did you ever figure out what the cause was? I'm having similar problems...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2005 at 10:17 pm
Finally, the voice of reason. I agree with Kenneth 100%.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 31, 2005 at 9:40 pm
Sure, Marilou,
To make a really long story shorter, if you have triggers, procs, whatever, all vying for the same row to update in a tracking table as...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 30, 2005 at 8:14 pm
Great lead-in article, Steve. I sat across from our two DBA's and it's amazing with what they have to put up with and what they have to do on a...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 30, 2005 at 5:45 am
We do not use Oracle contenization characters is MS SQL Server
and I'm pretty sure "For 1" just isn't going to hack it...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 29, 2005 at 8:41 pm
I don't understand exactly why you are trying to do this BUT...
Instead of redeveloping the wheel... STEAL!!!! Copy sp_HelpText from the Master database and make the following changes...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 29, 2005 at 5:59 pm
If you're not trying to do this in a script and just see or edit what's in the proc, open Query Analyzer, press [f8] to view the object tree, find the...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 28, 2005 at 5:48 pm
Yup, once I identified the problem and fixed it, we went back to zero deadlocks. Just wanted everyone to know that this type of thing, if done incorrectly, can really...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 28, 2005 at 6:07 am
We had someone do a similar thing at work and it caused, on the average, of 624 deadlocks a day because they used UPDATE instead of INSERT. And we only have...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 27, 2005 at 2:42 pm
Just to round out the list of possible solutions... 
--===== Find number of days in current month
SELECT DATEPART(dd,DATEADD(mm,DATEDIFF(mm,0,GETDATE())+1,0)-1)
It works by finding the first day...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 27, 2005 at 2:19 pm
Viewing 15 posts - 58,786 through 58,800 (of 59,063 total)