Viewing 15 posts - 50,161 through 50,175 (of 59,099 total)
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
bullcrap420 (6/5/2008)
Please let me know if you concur or know of an easier or better way to accomplish this.Thank you!
Heh... I don't concur with any of what you're trying to...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 5, 2008 at 4:54 pm
I agree... it'll likely require a change to the sproc or a bit of very clever SQL Injection and then only if the sproc is vulnerable.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 5, 2008 at 4:46 pm
I think you guys might be missing something... Yep, I'm sure that you're preaching to the choir when it comes to running jobs at night, etc...
The real problem the OP...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 5, 2008 at 4:35 pm
Viewing 15 posts - 50,161 through 50,175 (of 59,099 total)