Viewing 15 posts - 57,046 through 57,060 (of 59,067 total)
I screwed up... that's what I get for late night programming... I don't know what on Earth made me think that @@ROWCOUNT would ever be a NULL. If you want...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 18, 2007 at 6:15 am
If you expect a lot of rows with more than 1 space before the "\", this might be a lot faster...
--===== Execute the "single statement" update to...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 17, 2007 at 10:00 pm
Absolutely... in the code that follows, only the third "paragraph" is required... the rest is just setting up for the test. Of course, you will need to delete all but...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 17, 2007 at 9:45 pm
--===== Build some test data so we can demo the solution
CREATE TABLE #YourTable (PermitNum VARCHAR(10),EventDate DATETIME ,EventDesc VARCHAR(20),EventDateID INT)
INSERT INTO #YourTable
(PermitNum,EventDate,EventDesc,EventDateID)
SELECT 'PSD-1206','5/11/06','App Received',1 UNION ALL
SELECT 'PSD-1206','5/25/06','Determination',2...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 13, 2007 at 8:01 pm
CHAR(10) is the same thing as \n... use one or the other but not both.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2007 at 6:40 pm
No response... guess it's no longer a priority, eh? ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2007 at 6:11 pm
Yes, some of the BCP command line is order sensitive... most of the "switches" are not but the other stuff typically is.
So far as the "other" application goes, most folks...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2007 at 6:05 pm
Nope... you using single quotes in the first attempt... you correctly used double quotes in the second attempt.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2007 at 5:44 pm
Ronald's suggestion will certainly work but it's a pain if you have a bunch of named indexes, constraints, and the like...
If you'd take the time to post the schema (CREATE...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2007 at 5:37 pm
Agreed on all points... I have the same problems with a batch scheduling program at work because they don't know how to and/or won't use the SQL Job scheduler. Then...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2007 at 5:14 pm
Heh... THAT can be done! But I absolutely agree... The requirements that some of these folks have to put up with is insane.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 9, 2007 at 5:29 pm
Yep... whichever one ran first on my box, lost by about a second. Then, I removed the drop from both, whichever one ran first, also lost by about a second. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 9, 2007 at 5:47 am
The SQL Server "Service" must be logged in as a user that can "see" those remote paths. As Lynn said, that also means that user must have permissions to see...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 8, 2007 at 8:28 pm
Now, reverse the test... do it with the NO DROP first...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 8, 2007 at 8:18 pm
First, don't use ISQL... it's quite a bit deprecated when compared to OSQL which you should use instead.
Second, yes, both your BCP and OSQL should be very close... probably the...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 8, 2007 at 6:26 am
Viewing 15 posts - 57,046 through 57,060 (of 59,067 total)