Viewing 15 posts - 57,496 through 57,510 (of 59,067 total)
Thanks Serqiy. Nope, I haven't actually lost my mind (yet). I think just about everyone except the guy who wrote that knows that creating indexes on bit columns is a...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 3, 2006 at 6:06 am
I dunno wth he found but I kinda like the looks of the calculated column... could be sargeble that way... ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
October 2, 2006 at 8:49 pm
I'm a bit confused... are you trying to import the file (your comment about Bulk Insert) or are you trying to export to a text file and have the date...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 2, 2006 at 8:43 pm
This should pass your Use Cases...
--=============================================================================
-- Setup for testing
--=============================================================================
--===== System presets
SET NOCOUNT ON
--===== If the temporary test table exists, drop it
IF OBJECT_ID('TempDB..#Customer') IS NOT...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 2, 2006 at 8:28 pm
WTH? Why can't you use stored procedures or a UDF? Yeah, I know... "Business Requirement". WHAT is that business requirement?
--Jeff Moden
Change is inevitable... Change for the better is not.
October 2, 2006 at 7:55 pm
Oh yeah... one other question... are you trying the latest code with the UPDATE/INSERT where there are no SELECTs?
--Jeff Moden
Change is inevitable... Change for the better is not.
October 2, 2006 at 7:52 pm
I ran into something similar... if you drop and recreate a table, the views associated with that table must be recreated, as well. Are you sure you didn't recreate the...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 2, 2006 at 7:51 pm
Cluster the IDENTITY column if you wish... the natural key you are inserting to should not be clustered for the very reason you mention.
On the ROWLOCK on the SELECT... go...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 2, 2006 at 5:48 pm
Why? My last solution has no SELECT whatsoever... ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
October 2, 2006 at 5:40 pm
I guess that's where I was going with that, David... I'm trying to stay away from the sub-query and it came out wrong.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 2, 2006 at 6:53 am
If the ROWLOCK,HOLDLOCK works to keep the PK violations out, that'll work... I was peeling 1 potato at a time
How's the deadlock...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 2, 2006 at 6:36 am
I'm trying to stay away from SELECT at all, Serqiy... ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
October 2, 2006 at 6:34 am
I stand corrected. Thanks David. ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
October 2, 2006 at 6:27 am
Nice, but if you ever end up with 3 entries for a property, your method won't work. ![]()
But, this will...
SELECT MAX(ID) AS...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 1, 2006 at 9:23 pm
Greg,
It would appear that your TimeIn column could have the following formats...
6:15 a.m.
12:15 p.m.
6:15 p.m.
12:15 a.m.
The periods in the "a.m." and "p.m." could make this a bugger to convert. Even...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 1, 2006 at 9:20 pm
Viewing 15 posts - 57,496 through 57,510 (of 59,067 total)