Forum Replies Created

Viewing 15 posts - 61 through 75 (of 232 total)

  • Reply To: Returning Info from Stored Procedures

    dotathinker wrote:

    How about temptables, session context, CLR functions, etc.?

    Yeah, using temp tables is absolutely a workable solution, as is session context. CLR functions probably not, unless they utilize some external...

  • Reply To: Returning Info from Stored Procedures

    Lynn Pettis wrote:

    I doubt that using PRINT to return information is used on a regular basis.  The only time I use PRINT for the purpose is for debugging a procedure I...

  • Reply To: Returning Info from Stored Procedures

    Carlo Romagnano wrote:

    From any application (via ODBC or DB-LIBRARY) you can get the text returned from PRINT. In dblibrary you should use

    int msg_handler(DBPROCESS *dbproc, DBINT msgno, int msgstate, int severity,char *msgtext,...

  • Reply To: Returning Info from Stored Procedures

    Carlo Romagnano wrote:

    Rune Bivrin wrote:

    Carlo Romagnano wrote:

    5

    Also with PRINT and RAISERROR

    By that reasoning you should also include THROW, as well as modifying data in tables (particularly temp tables created by the caller).

    Personally, I...

  • Reply To: Returning Info from Stored Procedures

    Carlo Romagnano wrote:

    5

    Also with PRINT and RAISERROR

    By that reasoning you should also include THROW, as well as modifying data in tables (particularly temp tables created by the caller).

    Personally, I would not...

  • Reply To: DBCC Meaning

    Unless my memory is completely shot, back in version 1.1a (yes, I'm that old / started that young) it really stood for "Database Consistency Check". That was pretty much all...

  • Reply To: Calculate the Days Between First and Last Orders

    Good one!

    Until I understood the framing context, I used to do the LAST_VALUE as FIRST_VALUE(.. ORDER BY [col] DESC), which works out the same, but is likely a worse approach...

  • Reply To: Auto Rounding

    Nice question, which required a fair amount of reading and calculating back and forth.

    But there is a small issue with the "correct" answer: There is one zero missing in the...

  • Reply To: Float Issues

    Jeff Moden wrote:

    Opinion noted... However, I can more easily do things with DATETIME that can only be dreamed of with DATETIME2.  Even Microsoft realized their mistake but, instead of fixing it,...

  • Reply To: Float Issues

    Possibly, but then again, we all know how much accountants love guesswork, right 😀

    Anyway, I could easily dig up examples from the EU where the conversion rates between the EURO...

  • Reply To: Float Issues

    Jonathan AC Roberts wrote:

    I think there are accounting standads that say 4 d.p. should be used for money calculations.

    Well, that would depend on your country of operation, wouldn't it?

  • Reply To: Float Issues

    roger.plowman wrote:

    Actually, MONEY is useful if only for documentation purposes. You could use decimal but why would you want to? Being an integer makes the type faster than decimal.

    DATETIME does...

  • Reply To: Float Issues

    Yes, because MONEY is a precise data type with 4 decimal places. It's implemented as a 64-bit integer, scaled down by 10000. That and DATETIME must be the two lamest...

  • Reply To: Float Issues

    Jonathan AC Roberts wrote:

    I think the extra decimal digit is because if you multiply a number with 2 decimal places by a number with 1 decimal place, the result can have 3...

  • Reply To: Float Issues

    Jonathan AC Roberts wrote:

    Yes, a strange result. Try this:

    DECLARE @tmp1 FLOAT = 0.289;
    SELECT CONVERT(decimal(38,36),ROUND(@tmp1, 2)*100),
    CONVERT(decimal(38,36),ROUND(@tmp1, 2))*100

    Well, that's no more strange than any...

Viewing 15 posts - 61 through 75 (of 232 total)