Thread: RE: [INTERFACES] More VB

RE: [INTERFACES] More VB

From
"Ansley, Michael"
Date:
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.