Viewing 15 posts - 616 through 630 (of 2,038 total)
Tom Brown (6/18/2009)
Bruce W Cassidy (6/17/2009)
Tom Brown (6/17/2009)
Time for a nice Merlot.
[font="Verdana"]I like my merlots, I admit. But I have been more keen on syrahs (shiraz for you aussies)...
June 18, 2009 at 6:23 am
Forget my previous post!!!
Sorry!
June 17, 2009 at 10:49 am
Jeffrey Williams (6/17/2009)
Hmm - works fine for me. Are you sure it isn't failing because you already have a row with a 1 in the X column?
Well, I'm out...
June 17, 2009 at 10:48 am
GilaMonster (6/17/2009)
Paul White (6/17/2009)
June 17, 2009 at 10:39 am
@Jeffrey:
Erm... Just played with this nullbuster. This might be an important information for you:
This feature works find on SSE2k5 but it does not work anymore on SSE2k8 for bulk inserts...
June 17, 2009 at 10:34 am
Heh... Congrats Jeffrey; a new bookmark in browser for this topic 🙂
Using an indexed view is a solution I really had to see. Let me justify with the lack of...
June 17, 2009 at 9:48 am
Hi Jeff!
My solution definitely may become a performance issue with huge load. I just have no idea how you would handle this with DRI? (Maybe depends on the fact that...
June 17, 2009 at 9:08 am
Dugi (6/17/2009)
[bI agree with Florian ...but sometimes they are very nice objects to control (delete, insert or update) actions!
Hi Dugi
A mouse disagrees with a cat? Brave mouse! 😀
Joking aside...
You are...
June 17, 2009 at 7:40 am
In your case I would use a CHECK constraint in combination with a scalar function.
I just wrote a sample in another thread:
http://www.sqlservercentral.com/Forums/FindPost736516.aspx
I don't like triggers very much and try to...
June 17, 2009 at 7:25 am
You can handle this with CHECK constraint and a user defined function. Create a function which determines if a specified name is NULL or does not exist in the table...
June 17, 2009 at 7:14 am
There is no reason for the cursor. Try a joined UPDATE to get less code and much better performance:
UPDATE t SET
t.Code = md.Code,
...
June 17, 2009 at 6:46 am
Nice article!
Another reason for the "tomorrow technology" I heard sometimes:
"Tomorrows hardware will fit the performance lack of object databases"
Problem
"Tomorrows data have tomorrows storage and performance requirements"
😉
Again, really nice article!
Flo
June 17, 2009 at 6:38 am
So try this:
DECLARE @Txt VARCHAR(10)
DECLARE @Bin VARBINARY(6)
SELECT @Txt = '0102030405'
SELECT @Bin = 0x0
UPDATE t SET
@Bin = @Bin + CONVERT(BINARY(1), CONVERT(TINYINT, SUBSTRING(@Txt, (N *...
June 17, 2009 at 6:27 am
Could you post the DDL (CREATE statements) for your tables "dbo_ISD_Lease" and "dbo_Remedy Import" please?
June 17, 2009 at 6:20 am
Viewing 15 posts - 616 through 630 (of 2,038 total)