Viewing 15 posts - 50,161 through 50,175 (of 59,102 total)
Crud... I just realised this is for integration services... hope what I wrote for you still works...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 7, 2008 at 6:20 pm
Kind of... if both datatypes, 1 for the function and 1 for the column, are datetime, why not use that to your advantage?
DECLARE @Today DATETIME
DECLARE @Tomorrow DATETIME
...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 7, 2008 at 6:18 pm
Please read the article at the URL in my signature before you post again. You're post should have looked like the following...
--===== Setup the test table
...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 7, 2008 at 1:33 pm
Of course, you also realize how dangerous this is? If you were to change the price on an item list, you would change all orders that referenced it ......
--Jeff Moden
Change is inevitable... Change for the better is not.
June 7, 2008 at 1:08 pm
You can have a computed column that automatically does this. A computed column really doesn't like to refer to other tables or even other rows. Certainly, they don't...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 7, 2008 at 12:53 pm
I don't believe you need the "@" sign. Also, what datatype does the function return? If one or both are datetime datatypes (like GETDATE() is), then you can...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 7, 2008 at 12:47 pm
Use bulk insert to import the file into a table and join to it as you normally would.
As an alternative, you could Create a Linked Sever or OPENROWSET and read...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 7, 2008 at 12:28 pm
The formula in the following article will calculate weekdays without a loop. There is, however, no consideration for holidays...
http://www.sqlservercentral.com/articles/Advanced+Querying/calculatingworkdays/1660/
--Jeff Moden
Change is inevitable... Change for the better is not.
June 7, 2008 at 12:21 pm
Yep... make sure that nothing under spid 50 is affected in this manner. System would hate it...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 6, 2008 at 6:34 pm
What are the bounds of the missing dates? Gotta know what you require as a Non-missing date before we can find missing dates.
Also, storing dates as NVarchar is a...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 6, 2008 at 5:54 pm
Heh... bad day getting worse ol' friend? 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
June 5, 2008 at 6:13 pm
Are you using a loop of any kind in the data load process?
--Jeff Moden
Change is inevitable... Change for the better is not.
June 5, 2008 at 6:07 pm
We're still waiting for you to post something that can actually be troubleshot...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 5, 2008 at 6:05 pm
Another way is to import the spreadsheet into a table as is... then, do something like this to normalize it...
SELECT Vendor,Name1 AS Attendee
FROM sometable
UNION...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 5, 2008 at 5:07 pm
Yes... same solution... just export the data as tab delimited and do the split on the tab.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 5, 2008 at 5:03 pm
Viewing 15 posts - 50,161 through 50,175 (of 59,102 total)