Re: SQL ERROR ==> 461: File Open Error

In article <2caup9INNb17@emory.mathcs.emory.edu> gzhao@bbt.com (Guochun Zhao) writes: > >We have recently installed the Informix SE5.00 into our Sun SPARCstation >running SunOs, OPEN LOOK and NFS. We have encountered a sql error >message 461: File Open Error. Funny thing you should mention this.... We had the same thing happen to us just yesterday under SunOS 4.1.3, SE 5.01.UC1. It seemed pretty clear that it was either an OS or engine problem, because it was occurring for several unrelated databases that had previously been working OK. It was also interesting that we could create a new database using dbaccess, but when dbaccess went to access the new database as the last part of the Create command, it again got error 461. The primary sysadmin *had* been working on the system, but not in any areas related to either Informix or any of the database directories to the best of his recollection. File modification times seem to bear this out. You may not like this next part: It suddenly started working, but we don't know why. At least, I don't. I was watching over the sysadmin's shoulder, but not closely. He checked a few mounts, and we did some other looking around. I don't think anything was changed. All of the file systems involved are local. None are even exported. We did all of the aforementioned checking around from personal login's. All DB operations were still broken. Then, the sysadmin su'ed to root. He probably tried this for several reasons, one of which is that we had some getcwd() problems when we moved from I4GL 2.10.03 to 4.10. We use a setuid front-end to our production applications, which had stopped working with 4.10. These 461 problems were occurring with straight dbaccess, though, not any of the setuid stuff. Anyway, as I recall the session, all he did was su to root, create a database (which went OK!), then return to his personal login. After that, everything worked fine. We currently have a rather convoluted OS and network set-up here, so I figured maybe there's some problem with that. Our environment will be much more simplified soon, so we let it go. Now that I hear that someone else has experienced this problem, I'm nervous again. We have an important application scheduled go to into production soon. If anyone has any related experience or information, I'd appreciate hearing from them ASAP. Thanks, Walt. -- Walt Hultgren Internet: walt@rmy.emory.edu (IP 128.140.8.1) Emory University UUCP: {...,gatech,rutgers,uunet}!emory!rmy!walt 954 Gatewood Road, NE BITNET: walt@EMORY Atlanta, GA 30329 USA Voice: +1 404 727 0648