Viewing 15 posts - 52,591 through 52,605 (of 59,072 total)
I'm thinking a simple looping DOS batch file would work just fine... either that or maybe a simple VB script.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2008 at 7:29 pm
WHAT do you mean by "Transaction ID"? Do you mean the level of nesting within the transaction or do you mean the IDENTITY number of a row you just...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2008 at 7:25 pm
Post the table schema and the columns you would consider in deciding if a row where a duplicate or not... there's hardly any reason to go to text files and...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2008 at 7:23 pm
Because of implicit conversions.
A better question would be...
... why are you copying INT data into an NVARCHAR column to begin with?
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2008 at 7:21 pm
itortu (2/11/2008)
i do have hu_id on the result dataset i pasted above.
Yes, you do... but not in the code you posted... we can't tell which table hu_id is in.
Also,...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2008 at 7:16 pm
For starters, this....
WHERE CONVERT(VARCHAR, tblRFXProjecto.tmsCreated, 103) = CONVERT(VARCHAR, getdate()-1, 103)
... will not allow indexes to be used effectively because of the forced scan created by wrapping the column reference in...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2008 at 7:09 pm
I guess my question would be....
... what in blazes do you think you need to do in a database that can't be done in T-SQL?
The only possible exception to that...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2008 at 6:55 pm
Only way I can see that happening is if dbatools_filesize has two rows for each day for each database in it. Recommend you do a dupecheck to see...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2008 at 6:49 pm
Jesse McLain (2/11/2008)
BULK INSERT Import
FROM 'C:\Import.txt'
WITH (FIELDTERMINATOR = '","', ROWTERMINATOR = '"', FIRSTROW=3522350, LASTROW=3522360, MAXERRORS =...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2008 at 6:47 pm
Luk (1/28/2008)
no it doesn't. it gets created and then deleted when the transaction is rolled back.
Heh... listen to what you just said... "it gets created... and then deleted WHEN...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2008 at 6:41 pm
What are the datatypes and, if appropriate, sizes for the 5 different columns you're pulling from, Greg?
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2008 at 6:34 pm
That's normally the way I do it, too.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2008 at 6:29 pm
Absolutely perfect, Chris... I've always wondered why people try to do it the hard way.
Another way to do this is to simply have 2 tables and a view. While...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2008 at 6:20 pm
Craig,
This would be a lot easier to test code for if you provided some data and table schema info. See the following for how to do that effectively...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2008 at 6:11 pm
First, since you don't have HU_ID in any part of your query, you need to tell us which table it's in.
Second, I think you also have dupes in the bcustomer_notification_call_list...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2008 at 6:05 pm
Viewing 15 posts - 52,591 through 52,605 (of 59,072 total)