No, it's not, as some people, including me, will tell you, from bitter
experience. The problem is some of the types that are used by the library.
VB doesn't handle certain C types very well, there are better COM types that
support the VB interface quite handily, and it's better to use C to do the
casting.
MikeA
Byron Nikolaidis wrote:
>> Tom Lane wrote:
>> >
>> > "Stephen Martin Trans-Euro I.T Ltd" <stephen@sealteam.demon.co.uk>
writes:
>> > > whilst it seems driving libpq.dll from VB might be a difficult
>> > > enterprise.. is it still not possible to just connect a socket to
>> > > port 5432 of where ever and start communicating with postgres through
>> > > a socket? TCP or UDP?
>> >
>> > Sure, if you can cope with binary-oriented data structures being
>> > returned to you by the server. (The actual data is text, as long as
you
>> >
>>
>> I think I missed part of the conversation, but my take on it
>> is that if
>> you already have a "libpq.dll", it should be fairly
>> straightforward to
>> map the functions of the dll to VB, just as long as the dll follows
>> certain rules in how it exports the functions. I have created dll's
>> before, and mapped the functions to VB quite successfully. The only
>> thing to worry about on the VB side is to correctly map the
>> 'C' function
>> arguments and return values to VB data types.