Error during Execute sp with IMAGE parameter

Hello.
It is the first time that Im using IMAGE field type..

I created a stored procedure that should return an IMAGE field back to a
c-sharp program .
(@.OutImg IMAGE declared as an output parameter of the procedure.)
(Select @.OutImg = ImgFld from table)
Well,I can compile it , but when execute i get this error :
Msg 2739, Level 16, State 1, Line 14
The text, ntext, and image data types are invalid for local variable.

Is there something I can do ,OR should I use any cast/convert func to solve it ..?
Many thanks.:ofrom 2005 BOL:

text, ntext, and image parameters cannot be used as OUTPUT parameters, unless the procedure is a CLR procedure.

So you'll have to return this in a record set, not in an OUT param.

error creating cursor handle

this is the message wath i got back from a simple table update procedure
error creating cursor handle
WHY??which database engine do you use?
how is anyone supposed to figure out what went wrong if you don't post actual simple table update procedure?
does this error have error code? If so, which one is it?|||the error was solved on anodher forum|||So you cross-posted this message. Generally, it is a bad habit - it causes confusion (should I answer this question or that?). But, if you've already done that, you could have posted link to the answer too.

Error connecting to datasource using bulk load

thanks for getting back to me. I am able to connect to the database
elsewhere in the application to call stored procedures and retrieve the
data to display. This is the only place within the application that I am
unable to connect. I suspect it has to do with the fact that I am
calling within a single thread. Here is the connect string:
"Data Source=(local);Initial Catalog=IOC;User
ID=sg2user;password=sg2user"
franksag
Posted via http://www.codecomments.com
Try setting the Provider=sqloledb value in the connection string. Here's an
example from our docs of Bulkload in .NET:
[STAThread]
static void Main(string[] args)
{
try
{
SQLXMLBULKLOADLib.SQLXMLBulkLoad3Class objBL = new
SQLXMLBULKLOADLib.SQLXMLBulkLoad3Class();
objBL.ConnectionString =
"Provider=sqloledb;server=server;database=database Name;integrated
security=SSPI";
objBL.ErrorLogFile = "error.xml";
objBL.KeepIdentity = false;
objBL.Execute ("schema.xml","data.xml");
}
catch(Exception e)
{
Console.WriteLine(e.ToString());
}
}
"franksag" <franksag.1llvtp@.mail.codecomments.com> wrote in message
news:franksag.1llvtp@.mail.codecomments.com...
> thanks for getting back to me. I am able to connect to the database
> elsewhere in the application to call stored procedures and retrieve the
> data to display. This is the only place within the application that I am
> unable to connect. I suspect it has to do with the fact that I am
> calling within a single thread. Here is the connect string:
> "Data Source=(local);Initial Catalog=IOC;User
> ID=sg2user;password=sg2user"
>
> --
> franksag
> Posted via http://www.codecomments.com
>

error code from DTEXEC not 0 nor 1

I would like to send back to MS-DOS (ERRORLEVEL) an error code 2 ( different from 0 and 1) via a scripting Task.

Our package are started with the DTEXEC Utility.

In general, how can i send back a flag saying "There were warnings" during the execution of a Package

Warnings can happen with successful package executions, and for that matter, so can errors.

There are a numerous ways to figure out there were warnings though, such that a shell caller is aware of that fact.

One, capture the console output from dtexec and look through the captured text for the warning event.

Two, create a console utility which calls Package.Execute() and iterates through the .Warnings collection. If the count > 0, return what you want as the process exit code.

Three, use logging. Configure the package to use the native SSIS logging facilities to write log entires. Read the produced log provider for warning events.

Four, use a package level OnWarning event handler. Inside the event handler, set something external to the package (file, db, message queue, doesn't matter) which is readable post-execution.