Viewing 15 posts - 58,561 through 58,575 (of 59,091 total)
Shrikant,
This will do it provided your tables correctly have a primary key (composite 2 column PK in this case)... first, the usual disclaimer because this is a data altering script...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 19, 2005 at 7:19 am
Shrikant,
Yes, but I need a little more info...
1. Do the tables have a Primary Key?
2. How many rows does the biggest table have?
3. Are you allowed to use temporary tables?
--Jeff Moden
Change is inevitable... Change for the better is not.
December 19, 2005 at 5:52 am
Ziga,
To do a nearly perfect distribution of random numbers across 3 sets, use the following to overcome the up-rounding that is inherenent in an INT column (you could use TinyInt...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 19, 2005 at 5:42 am
Easy enough...
First, let's take care of adding the ID column, filling it with numbers from 1 to n, and making it the Primary Key... we're going to do it without...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 18, 2005 at 5:47 pm
Ziga,
The reason for the error is you have not FETCHed anything.
Shifting gears... I know you think you need a cursor for this, but you do not. I will admit...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 18, 2005 at 2:07 pm
Ok, just for fun, the following code will report ranges of both present and missing ID's. Why do it this way? Because if you have a huge number of missing...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 18, 2005 at 11:04 am
Interesting... THAT allows you to use sp_ExecuteSQL with more than 4k bytes? I gotta try that.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 18, 2005 at 8:14 am
No need to be sorry... most of us have made the same mistake early in our SQL careers. Those that say they didn't... are lying. ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
December 17, 2005 at 11:37 pm
Sure, one complete explanation coming right up... but I'm a bit surprised you didn't figure it out yourself... remember, you asked the question...
First, I modified your code so we could...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 17, 2005 at 11:04 pm
Don't use sp_Execute. Just use EXEC...
EXEC (@SQL1+@SQL2+@SQL3....+@SQLn)
... and each of the variables can be VARCHAR(8000).
--Jeff Moden
Change is inevitable... Change for the better is not.
December 17, 2005 at 10:13 pm
dba321,
The Inserts that Phil provided are just test code to simulate your much larger table (or result set, whatever)! You don't need any of those Inserts and you certainly don't...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 17, 2005 at 10:04 pm
You certainly don't need a cursor and, if you don't want, you don't need a function... "Trust the force, Luke."
SELECT CONVERT(VARCHAR(10),SecondsCol/86400)+':'
+ CONVERT(VARCHAR(8),DATEADD(ss,SecondsCol,0),108)
FROM yourtable
The forces to...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 14, 2005 at 11:08 pm
I don't think he meant to be sarcastic... he was just having fun and beat most of us to it. It's hard to tell in email when someone is joking...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 13, 2005 at 9:18 pm
It's customary to share your final solution, if you don't mind.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 12, 2005 at 7:05 pm
Jon,
David is correct... since Julian dates recycle every 10 years, should we assume that you will never have a future dated Julian date?
Also, would you rather (recommended) have the date...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 12, 2005 at 7:02 pm
Viewing 15 posts - 58,561 through 58,575 (of 59,091 total)