Viewing 15 posts - 55,696 through 55,710 (of 59,098 total)
No... not ready to make that recommendation. We first need to identify what change was made to cause the code to suddenly go south several days ago. Quick fix would...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2007 at 8:22 am
Run the following...
DBCC USEROPTIONS
... which will produce something like this...
Set Option Value
textsize 64512
language us_english
dateformat mdy
datefirst 7
quoted_identifier SET
arithabort SET
ansi_null_dflt_on SET
ansi_defaults SET
ansi_warnings SET
ansi_padding SET
ansi_nulls SET
concat_null_yields_null SET
(12 row(s) affected)
DBCC execution completed. If DBCC printed error messages, contact...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2007 at 8:11 am
Ok... not the explanation I was looking for but I guess it'll do.
If you want to round to a single decimal place, then convert it to to something like DECIMAL(19,1)...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2007 at 8:02 am
It's ok... heck, I guess I don't blame you about the bump on a busy forum. When you need an answer, you need an answer and a relatively harmless bump...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2007 at 7:53 am
Heh... ok... not sure that's better or worse but at least its not a desparate human
Thanks, Rainer.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2007 at 7:48 am
I'd recommend that changing the timeout is a patch, not a fix. All you'd end up doing is allowing code that desparatly needs to be fixed to take its sweet...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2007 at 7:46 am
Did the problem happen to start on the 13th of July? Sounds like someone may have changed the default date format from dmy to mdy and your code isn't handling...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 23, 2007 at 11:54 pm
Everyone is forgetting about the "other" problem... the excessive row sizes that arise when doing the table ALTERs for the nocheck of constraints. It means that one or more of...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 23, 2007 at 11:52 pm
You may want to try using DBCC FREEPROCCACHE. If that doesn't do it and it's a GUI proc, you may have to clear cache for the application. Since I don't...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 23, 2007 at 11:40 pm
Ram,
Dunno about the others, but I need to know why you want to simply throw away so many decimal places especially since the target datatype (Money) has 4 decimal places...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 23, 2007 at 11:31 pm
I agree... bad message to promote and, depending on what the server is doing, if you down it, you could cost someone their life (seriously... 911 control server, traffic light...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 23, 2007 at 11:18 pm
Like I said on the other forum, I think you have a bit of a technical error in the code. I think this...
ImportFullPath = ImportPath & ImportFile
... should be this...
ImportFullPath...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 23, 2007 at 11:12 pm
This is what I call "RBAR" (pronounced "ree-bar" and is a "Modenism" for "Row by Agonizing Row") because you have variables on the right side of an update. The only...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 23, 2007 at 11:10 pm
Thank you for the detailed explanation... I have just a couple more questions , if you don't mind...
Can you post the table of results for the "A" items?
In the formula 18(18)+18(18-15), do...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 23, 2007 at 9:52 pm
Very nicely stated and explained, Steve.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 23, 2007 at 9:40 pm
Viewing 15 posts - 55,696 through 55,710 (of 59,098 total)