Обсуждение: [Fwd: errors in psqlodbc]

     I'm not sure you are the person to recieve these.  If not, could you
     pass them along.

     These problems were found when installing postodbc on sun solaris
     2.5.1.  It could be that some of these would not be errors on some
     other OS.

     connection.c.  A seg fault occurs when writing to one of the log
     files.  The problem is a null pointer.

     misc.c.  If log files are written by one user, then the next user
     cannot reopen or replace the files since they are owned by the first.
     There the fopen returns a null pointer and causes a segmentation
     error.

     gpps.c.  There were several errors in the implementation of
     GetPrivateProfileString and WritePrivateProfileString.  The principle
     problem was that iodbc and psqlodbc ended up pointing to different ini
     files.  I used this code in another application and implemented all
     the features of the Window's APIs.

     I think the code to read the ini files should be in iodbc not each
     client.  I have received three different iodbc's from postgres, mysql,
     and openlink distributions.  All three slightly different.  And most
     of the differences are in the handling of ini files.

     I am sending my implementation of GetPrivateProfileString and
     WriteProfileString in files: profile.h, profile.c, and a test
     application testpro.c.

     One problem with the distribution of psqlodbc is that the linker
     switch -B symbolic causes 4 linker errors to be listed.  I did not
     know this was really OK, that the linker errors would be resolved by
     the dynamic loading.  Therefore, I wasted a lot of time trying to
     solve this problem that wasn't really a problem.  Perhaps, there
     should be some warning in the install documentation to expect these
     linker errors.

     John Sharp
     jsharp@cfipro.com
     sharp@cs.pdx.edu

Byron Nikolaidis wrote:
>
>   ------------------------------------------------------------------------
>
> Subject: errors in psqlodbc
> Date: Sun, 18 Oct 1998 22:01 -0800
> From: "John Sharp" <JSharp@cfipro.com>
> To: "byronn@insightdist.com" <byronn@insightdist.com>

Thanks Byron.

Looks like we have a new guinea pig :-).

John could you tell us which version of the driver your trying to build
with? If your using version 0.25 from the Insightdist download page than
I'll tell you right off that there have been some significant changes.
Mostly
involving configuration and building on Unix systems but I changed the
log file code to user "randomly" generated log files for each user.

As for your other problems I think they are best handled after we see
if they still exist in the newer code. So... if you don't mind being
a guinea pig we could send you the new code and see what changes need
to be made to make the driver work under Solaris?

Thomas if your out there I'll let you send John a tarball as I figure
your hanging on to the "semi-official" Unix source.
--
Gerald Gryschuk(ggryschuk@scf.sk.ca)
Programmer Analyst
Saskatoon Cancer Centre
((306)655-2746)

> Looks like we have a new guinea pig :-).
> Thomas if your out there I'll let you send John a tarball as I figure
> your hanging on to the "semi-official" Unix source.

How about if I send the new docs and the tarball directly to John? The
first round of testing indicated that some changes should be made in the
docs, so he could probably benefit from those.

I've sent another letter under separate cover trying to get this stuff
back in some order. I'll add John to the list of interested parties, and
we'll look to him for feedback.

btw, if we start making changes that are _not_ based on the current
Postgres cvs tree then we will have trouble making the v6.4 release.
Which would not be desirable :/

                     - Tom

Thomas G. Lockhart wrote:
> btw, if we start making changes that are _not_ based on the current
> Postgres cvs tree then we will have trouble making the v6.4 release.
> Which would not be desirable :/

Well..., than I guess we'll have to use that source for changes. Having
said that I think its entirely up to you and Byron to sync up this
source again. I for one don't want to see the two packages diverge
simply because they're on different platforms. Besides which because
of the new configuration files it should be a simple matter to release
what we have and than integrate Byron's changes or our own when new
platforms are added.

--
Gerald Gryschuk
gerald.gryschuk@home.com
MidNightOil Consulting - "We burn the midnight oil so you don't have
to."