Viewing 15 posts - 50,146 through 50,160 (of 59,091 total)
Post what you did for the problem... attach the spreadsheet you used if nothing private is in it.. let's give 'er a whirl. 😀
Any links I would be using at...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 8, 2008 at 5:50 pm
You didn't listen if you ended up using RBAR and hardcoded names... you didn't read the articles that were suggested well enough.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 8, 2008 at 5:32 pm
I can't duplicate the error. In other words, I get no error unless certain rows are being used by foreign keys.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 8, 2008 at 12:41 pm
Anirban Paul (6/5/2008)
why complain folks, question is good, only you have to read it long time to understand.....:)
The problem is that designers and PM's write the same kind of mistake.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 7, 2008 at 6:32 pm
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
Viewing 15 posts - 50,146 through 50,160 (of 59,091 total)