Viewing 15 posts - 52,096 through 52,110 (of 59,067 total)
Grant Fritchey (3/5/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
March 5, 2008 at 12:26 pm
Ok... thanks for the feedback...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 5, 2008 at 12:23 pm
Please post the actual query... there's no way the one you posted actually works.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 5, 2008 at 12:18 pm
It's certainly not automatic, but my first inclination is to ask...
1. You allow folks to change production stored procedures without DBA approval?
2. Are there no documentation standards? ...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 5, 2008 at 12:16 pm
Ok... since you can't actually see Ascii 26 except maybe as a supurious square, how can you tell the end of file marker is being loaded?
--Jeff Moden
Change is inevitable... Change for the better is not.
March 5, 2008 at 12:02 pm
Thanks TonyJ, It works but it doesn't work when u have this scenario
And, still, you haven't tried the solution that Ian posted which doesn't have that problem... 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
March 5, 2008 at 11:59 am
Ralph Curry (3/5/2008)
select
Widget,
DateValue
from (
select
...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 5, 2008 at 11:51 am
Heh... at least you tried. Thanks for the feedback.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 5, 2008 at 11:49 am
The end of file marker is typically an ASCII 26 and SQL Server will not read it in. You don't have to prevent it from happening.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 5, 2008 at 11:46 am
I could be wrong, but this sounds like a "running total" problem with an additional SELECT to find the 2 million mark... please see the following...
http://www.sqlservercentral.com/articles/Advanced+Querying/61716/
--Jeff Moden
Change is inevitable... Change for the better is not.
March 5, 2008 at 11:33 am
There's usually some merit and some future need for knowing the times. I think it's a huge loss of data to update datetimes that have the time to all...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 5, 2008 at 11:20 am
Can't help on the Reporting Services thing...
... But that's a cool avatar ...
... and my favorite NRA "saying" is "When they outlaw guns, only outlaws will have them."
--Jeff Moden
Change is inevitable... Change for the better is not.
March 5, 2008 at 11:16 am
Still, going the negative number route will likely only buy an addition year of time according to what was forecast by the OP. (18 months total... 6 months for +,...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 5, 2008 at 11:12 am
Heh... even worse... all we really need now is for Joe Celko to jump in with his ISO standard mantra... 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
March 5, 2008 at 11:06 am
Ok... it's a fun exercise, but I've gotta know... why did you folks decide to do one in SQL? I mean, what do you actually use it for? ...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 5, 2008 at 11:04 am
Viewing 15 posts - 52,096 through 52,110 (of 59,067 total)