Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > LLBLGen Pro Runtime Framework> Stored Proc call returns -1
 

Pages: 1
LLBLGen Pro Runtime Framework
Stored Proc call returns -1
Page:1/1 

  Print all messages in this thread  
Poster Message
JSobell
User



Location:

Joined on:
07-Jan-2006 06:44:46
Posted:
89 posts
# Posted on: 26-Oct-2015 09:34:55.  
Hi,
I'm using the latest LLBLGen, SQL2014, Adapter, SD framework, and when I call some stored procedures I'm getting a return code of -1. The procedure runs, and tracing shows no error, and overriding the end of the SP with a RETURN(0) still returns -1 from the .Call() on the engine.

What does -1 mean, and is any of this stuff documented? I've scoured the doco with no luck. Do we ignore the return code? What if we do want to return a return code?
Removing the contents of the SP makes no difference, so it's nothing to do with the SP itself. The call simply takes a UniqueIdentifier, and we only get -1 on some SP methods, not all.

Any suggestions?

Cheers,
Jason
  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37880 posts
# Posted on: 26-Oct-2015 10:08:50.  
The value returned is the value returned by DbCommand.ExecuteNonQuery. http://referencesource42.llblgen.com/#SD.LLBLGen.Pro.ORMSupportClasses/AdapterSpecific/DataAccessAdapterCore.cs,4131

Which is the # of rows affected. If it returns -1, it's likely you turn off ROWCOUNT in the procedure, is that correct?


Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
JSobell
User



Location:

Joined on:
07-Jan-2006 06:44:46
Posted:
89 posts
# Posted on: 26-Oct-2015 10:48:51.  
Hi Otis,
Yes, I just found the answer in the following Microsoft article:

https://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlcommand.executenonquery.aspx?f=255&MSPPError=-2147217396

It appears the rules for returning -1 are a little more complex than you might expect. The main thing is that the call ends in a standard ExecuteNonQuery(), which I just found on my home machine by viewing the source. I just wanted to check there wasn't an earlier (or later) code returned by the core DLLs due to something we had wrong.

All sorted now though! Thanks for the (as always) speedy response.

Cheers,
Jason
  Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.