Viewing 15 posts - 50,146 through 50,160 (of 59,099 total)
Heh... yeah... 648 of them were me trying to figure out your problem... 😉
I could make it 651 ya know... 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
June 9, 2008 at 6:54 am
I would think that a Linked Server would be able to do that... Search for it in Books Online for the details. They're pretty easy to make.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 9, 2008 at 1:09 am
The default declaration for NUMERIC (also known as DECIMAL) is 18,0 and takes 9 bytes to store. The max precision for NUMERIC at 9 bytes is 19,0 so if...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 9, 2008 at 12:51 am
Nicely done, Gus... Can't wait for the others!
--Jeff Moden
Change is inevitable... Change for the better is not.
June 9, 2008 at 12:19 am
Who does the pivoted data start out? In a spreadsheet or in a table?
If it's in a spreadsheet and you can't unpivot it there for some reason, then I'd...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 8, 2008 at 7:35 pm
Yes... it's so the system doesn't have to wait until your insert is done before anyone else can do an insert. If your insert fails (or you change your...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 8, 2008 at 7:25 pm
My turn to appologize... I though you were talking about unpivoting. What you did with the pivot is just fine. You can also do something similar with dynamic...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 8, 2008 at 7:18 pm
Heh... you still used dynamic sql... not so bad as RBAR, but post the spreadsheet you're trying to resolove... lemme take a whack at it.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 8, 2008 at 5:52 pm
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
Viewing 15 posts - 50,146 through 50,160 (of 59,099 total)