Viewing 15 posts - 54,286 through 54,300 (of 59,072 total)
Heh... yeah, and I absolutely agree... the "proper documentation" fairy got on my shoulder, again.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 6, 2007 at 8:28 pm
Sure it's easier... that's not the name of the game... name of the game is nearly-continuous availablity of the data... depending on the size of the table, you may have...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 6, 2007 at 8:25 pm
A really great way is to include some revision history in the header comments of the proc... you know... the same place where you identify what the proc does, what...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 6, 2007 at 8:18 pm
Do you mean that you need to drop the time before you compare? If so...
WHERE DATEDIFF(dd,Table1.TimeStamp1) = DATEDIFF(dd,Table2.TimeStamp2)
Do be aware that because you have column names in formulas, there...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 6, 2007 at 8:13 pm
Yes... it's \"... if you want to depict "," (quotes included), the delimiter would be identified as "\",\"" in the format file. But, beware... the first quote in the...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 6, 2007 at 8:06 pm
No, no... no transfer of data from TableA to TableB... it'll take too long. Go back and look at what we wrote...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 6, 2007 at 7:58 pm
Just a thought, folks... Much like Loner's process, I do a lot of ETL using Bulk Insert with format files. The difference is that I have all the files...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 6, 2007 at 3:47 pm
Loner (11/6/2007)
I created a table called TextFileInfo with TextfileName, Path directory, formatfilename with path directory,
table...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 6, 2007 at 3:12 pm
Yes all of the files in the same format ..
I would like to merge data from all of the files into one table. do you have any sugguestion or sample...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 6, 2007 at 3:10 pm
It's simple... convert all of those formats to datetime using just CAST... they'll all "fly" correctly... and convert them back to your YYYY-MM-DD format...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 6, 2007 at 2:54 pm
Heh... no question that with that many rows of data that you need to do some data marting and that you're not actually trying to create reports from nearly 400...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 6, 2007 at 2:47 pm
You didn't answer my question, though... Do you expect the right most bit of each of those groups to represent 20 in your returned decimal number?
--Jeff Moden
Change is inevitable... Change for the better is not.
November 6, 2007 at 12:24 pm
First of all, you need to count the bits from the right... not the left... and they should be counted as powers of 2 starting with the exponent 0... then...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 6, 2007 at 11:22 am
We don't have a single report that takes longer than 30 seconds to retrieve (typically they're in the 0-2 second range), thanks to some careful marting...
...Once I've gotten the data...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 6, 2007 at 10:49 am
karthikeyan (11/6/2007)
Thats why i posted...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 6, 2007 at 10:04 am
Viewing 15 posts - 54,286 through 54,300 (of 59,072 total)