Re: D3 odbc and .Net, almost there!

Tony Gravagno <address.is.in.posts@xxxxxxxxxxxxxxxxxxxxxx> wrote:
"frosty" wrote:

Wow... I thought the whole idea behind managed code was that it
didn't matter which compiler you used, because they all produced
compatible p-code.

You got it right J. I suggested to Gene that part of the problem was
that he was passing values ByVal instead of ByRef in his VB.NET code,
so he re-wrote the whole thing in C# and passed the values ByRef. He
was also passing in a String to capture the return value where he
needed a VB Variant, which in .NET is now an Object. So in the C#
code he's now passing Objects ByRef and it's getting closer. But the
same results could have been achieved in VB.NET or 30 other languages
that implement the CTS. Another factor is that the brOpenConnection
is now getting "ODBC" as the first parameter which wasn't in the VB
code. So this is very different code, not just translated.

As far as I know, you cannot explicitly pass variables by reference in VB.Net
unless the function is defined that way. ByRef is not valid outside a
function or subroutine definition.

The "ODBC" parameter is not required in the C4 version of the driver, which
is what my original example was based upon. It is NOT very different code.

The result CANNOT be replicated in VB.Net unless you're using something not apparent in the MSDN documentation for VS2k8.

I still maintain the D3CL won't be reliable because it was never
adapted to .NET. There's no telling what's under the covers and what
Frankly, that's pure nonsense. The DLL itself follows well known standards
and is apparently kept current. The C32 release was on 2/14/08.

As long as the functions are properly called through interop, there is no
reason to think it won't work properly. The reliability of the DLL won't
be any different whether you're calling it from VB6, C# or Delphi. As long
as the parameters are correct it will work because the standards for calling
a DLL are very well defined. Whether through a constructed Interop call or
directly via PInvoke, there is no reason that code shouldn't work properly.

I don't know what happened with RD on this one but so far I'm inclined
to agree with their stance that this stuff shouldn't work and can't be
I was never told "it didn't work". I was told that they don't support it
under .Net and was refused any further discussion or out of band suggestions.
Whether or not I was calling the DLL from VB.Net or Fortran is irrelevant.
It's a DLL, plain and simple. I obviously had a misunderstanding of how to
properly call the routine from a different language.

All I wanted was a little assistance or maybe a nudge in the right direction.
Instead I get flat refusals from the company I pay support for and FUD from
apologists.

I have no intention of using this for any longer than I absolutely have to.

I embarked on the effort again after finding a suitable replacment solution
simply because I can't stand to leave it alone knowing that it's utter
bull***. Telling me something isn't possible without proving it completely
is a sure fire way to get me riled up enough to spend the time to either
prove it does work or acknowledge defeat that it doesn't.

"You can't" is only 100% sure with me if I'm not breathing. :)

With the exception of the disconnect issue it works flawlessly, even on
the Windows 2008 Web Server VM I'm testing it on. I have a suspicion that
I've got either the driver incorrectly configured or the driver relies on a
bug or feature that I don't have with the 7.4.0 environment I'm using.

If after a reasonable effort I cannot make it work, I'll happily and publicly
admit defeat and eat my little plate of slightly undercooked crow.

However, if I can make it work, I'll post examples so that everyone can try
it if they like.

g.

.