RE: [INTERFACES] More VB

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(at)sealteam(dot)demon(dot)co(dot)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.