Viewing 15 posts - 58,831 through 58,845 (of 59,067 total)
Morean,
SellerTools' answer can easily be modified to handle 8000 characters just by changing "Declare @sql as varchar(200)" to "Declare @sql as varchar(8000)". Still, it's dynamic SQL and might be better...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 7, 2005 at 4:04 am
Actually, it can be done without the overhead of Dynamic SQL by using a CASE statement in the WHERE clause....
FROM Table1
WHERE Name = 'AA'
AND ID...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 5, 2005 at 9:44 am
A fellow on this forum who goes by the name of "Adam Mechanic" would have you create a permanent date table so that you can easily solve these types of...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 3, 2005 at 6:27 am
After reading the links that Frank posted and reading "Estimating Table Size" in BOL AND reading "Data Types" in BOL, I've kind of decided that it's just easier to remember...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 3, 2005 at 6:00 am
Guess I didn't know that... how do you forward reference a temp table?
--Jeff Moden
Change is inevitable... Change for the better is not.
March 2, 2005 at 7:52 pm
Thanks for the info!
--Jeff Moden
Change is inevitable... Change for the better is not.
March 2, 2005 at 7:47 pm
This could be converted to a UDF to replace GETDATE() with a date for the month to find the last business day of...
The time included in the date takes you...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 2, 2005 at 1:57 am
What's the lookup in BOL that proved so useful?
--Jeff Moden
Change is inevitable... Change for the better is not.
March 2, 2005 at 1:25 am
Nice job and you got right to the point. Great comparison example against derived tables. My hat's off to you.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 2, 2005 at 1:16 am
Concur... a world of hurt lays ahead for those using Unique Identifiers in a casual manner.
... and, I agree, the customer code is the unique number to be used as...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 28, 2005 at 9:27 pm
Like I said, you have to give the hint "FIRE_TRIGGERS" to get triggers to fire during a bulk-copy or bulk-insert. If you do that, then the inserts get "logged" in...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 28, 2005 at 9:02 pm
>"1000 Points whose values are coming after about every second"
Does this mean that the table grows by a thousand rows every second? If so, some well designed indexes would help. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 28, 2005 at 5:54 am
Not unless you specify the FIRE_TRIGGERS hint which also causes the operation to become fully logged.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 27, 2005 at 2:02 pm
Usman,
Charles is right, an IDENTITY column might help to guarantee row uniqueness is this case. However, whether you have an IDENTITY column or not (sometimes can't change a table because...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 26, 2005 at 11:41 am
Like I said, "Rather than using a view, ..."
--Jeff Moden
Change is inevitable... Change for the better is not.
February 16, 2005 at 6:22 pm
Viewing 15 posts - 58,831 through 58,845 (of 59,067 total)