[AccessD] Now that the SP_ExecSQL is working

I am guessing that it is exactly a "boundary" that causes 
these issues.  In VB, the program is all just one big blob 
of memory.  If I pass a variable or a pointer, the receiving 
object has access to the blob of memory and can just use a 
pointer because it can grab whatever it needs from wherever 
the pointer points to.

In the case of SQL Server, it runs "over there", often quite 
literally on a completely different machine.  As a result 
passing stuff back and forth is going to be very different. 
  Once you think about it that way it is obvious, but not so 
much when you are first trying to do this.  And with no 
experience, the syntax is going to be obtuse.  And of course 
(from one who William consistently calls obtuse) BOL is the 
very definition of Obtuse.

Being obtuse and understanding obtuse are two completely 
unrelated skills.  ;-)

John W. Colby
www.ColbyConsulting.com


Салахетдинов Шамиль wrote:
> John,
> 
> I do not know what happens on SP boundary while passing parameters on its call and getting their values back on return - I can only guess - I worked a lot in assembler in the past and I have seen what happens "under the hood" in FORTRAN, PL/I, COBOL, Pascal, C/C++ etc. while passing params back and force ...
> 
> For me it is also unclear why they (MS) require to specify OUTPUT keyword explicitly while calling SP...
> 
> Also missing OUTPUT keyword here, and "scratching my head" from time to time :)
> 
> Thank you.
> 
> --
> Shamil
> 
> P.S. In C# where OUT keyword is also required on both a method definition and its call, such OUT keyword allows to pass unassigned parameters as opposed to REF keyword, which requires params' variables to have a value assigned before calling a method - such value can be null but it should be explicitly assigned in code otherwise C# compiler reports compile error...
>