Viewing 15 posts - 52,426 through 52,440 (of 59,098 total)
Heh... sure you did... you learned that there's more than one way and that one of the ways will be easy. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
February 21, 2008 at 5:24 am
I understand... if "every code change can be acceptable", then consider implementing that which is found at the following URL:
--Jeff Moden
Change is inevitable... Change for the better is not.
February 21, 2008 at 5:12 am
What is the exact wording of the error?
--Jeff Moden
Change is inevitable... Change for the better is not.
February 21, 2008 at 4:22 am
Yeah... it's a simple "Name/Value" table that can easily resolved using various high performance methods (none of which require a CLR) including simple cross-tabs. What kind of an error...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 21, 2008 at 4:20 am
Simong,
Here's a simple "splitter" to normalize the CSV entries you have so you do a join instead of a "LIKE"...
--===== Create a table to hold user ids and a word...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 20, 2008 at 4:38 pm
tbeadle (2/20/2008)
[font="Arial"]There are word token subroutines available to help with loading the single field table.The comparison of the two table entries would be fairly simple at that point.[/font]
Good thoughts, Terry......
--Jeff Moden
Change is inevitable... Change for the better is not.
February 20, 2008 at 4:12 pm
Either way, looks like a correlated sub-query is going to be involved which is why Matt suspects the performance is going to suck a bit...
Here's another way (output could be...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 20, 2008 at 3:42 pm
Ya gotta make one...
--===== Create and populate the Tally table on the fly
SELECT TOP 11000 --equates to more than 30 years of dates
...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 20, 2008 at 3:09 pm
Nicely done, Lynn!
--Jeff Moden
Change is inevitable... Change for the better is not.
February 20, 2008 at 3:05 pm
Matt Miller (2/20/2008)
Would this have anything to do with using Native format (as opposed to character format?)
Man, I can't wait to get off this cold medication... I totally missed that...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 20, 2008 at 2:49 pm
Dang... I was loading up the double-barreled pork-chop sling-shot. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
February 20, 2008 at 1:25 pm
I'm with Michaeal... I'm not sure anyone would have entries for, say, 1754, or even 1901 and certainly not for the year 2100 or 2200. What I'm trying to...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 20, 2008 at 1:12 pm
No... if you don't specify the database or the server, it assumes the "default" database for the user (which has been nicely overcome by the 3 part naming convention) and...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 20, 2008 at 1:09 pm
I've never seen BCP do such a thing... what are you using to call the BCP with?
--Jeff Moden
Change is inevitable... Change for the better is not.
February 20, 2008 at 12:46 pm
I don't know what it is... everything in the command you printed looks fine. I even tried it with substitution of colums, etc, and it works just fine on...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 20, 2008 at 12:42 pm
Viewing 15 posts - 52,426 through 52,440 (of 59,098 total)