Обсуждение: [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."