Post reply

Return info to Client Application ?

  • February 19, 2005 at 1:46 pm

    #166033

    These are the ways I understand how to send info to the client application

    SELECT sends a recordset to ADO

    RETURN Status of procedure run

    RAISEERROR ( @@ERROR ) Error message ( like RETURN )

    OUTPUT PARAMETERS sending one or two variables  ( question can you send a table parameter to cleint)

    PRINT...can this send info to client, if so how, any examples ?? I thought this was just a debugging tool for building queries ??

  • February 21, 2005 at 7:43 pm

    #543388

    Don't know of a way to send the PRINT results to a client - without assigning it to another variable at least.

  • February 21, 2005 at 8:26 pm

    #543391

    Table variables cannot be sent to the client as this is an SQL Server specific datatype.

    The PRINT statement is handy for issuing status messages when you're executing an SQL statement, or procedure via Query Analyzer or OSQL. This is because it displays as a simple text message, rather than the fieldname/fieldvalue format that the SELECT statement uses.

    When you have a scheduled job that executes T-SQL with PRINT statements, the output is written to the SQL Agent log.

    In a client/server, or n-tier, application, PRINT returns messages as informational errors. For ADO you need to check the Errors collection.

     

     

     

    --------------------
    Colt 45 - the original point and click interface

  • February 22, 2005 at 11:50 am

    #543540

    So if I use PRINT in a batch, I can use Ado Connection object to read it via errors property. Is this correct ?

    Like

    Din Cnn as ado.connection

    Set cnn = SQL Server etc

    'Read errors, by looping thru

    cnn.errors

  • February 22, 2005 at 3:28 pm

    #543573

    That's what it seems like, although I've never implemented anything like that. My way of thinking is that the errors collection is for errors, not informational messages.

    If I have to feed informational, or status, messages back to the client, usually I log messages to a table. Generally any process that needs some sort of client feedback benefits from some sort of logging anyway. 

    More often that not these sort of processes happen on the server without any interaction with the client. Then if need be the client app just reads the messages from that table. Any "real" errors are feed back via RAISERROR.

     

    --------------------
    Colt 45 - the original point and click interface

  • February 22, 2005 at 10:06 pm

    #543604

    Thanks Philcart you last comments make best sense !

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply