RE: [INTERFACES] More VB
От | Ansley, Michael |
---|---|
Тема | RE: [INTERFACES] More VB |
Дата | |
Msg-id | 1BF7C7482189D211B03F00805F8527F70ED086@S-NATH-EXCH2 обсуждение исходный текст |
Список | pgsql-interfaces |
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.
В списке pgsql-interfaces по дате отправления: