Doug Sounds like your need to plan your next approach need to take a slight different tack. Perhaps with a effort to help isolate the UniObjects issue you have identified. As so far you've no luck with the various approaches you're spent many hours devoted to this tricky issue.
With issues like this...you have to ask the obvious question: "What has been changed?". This is assuming it all use to work fine before of course. It sounds like nothing has changed. From what you're posted so far. Is that correct? I guess you've confirmed this is not file corrupt issue with the UV files being accessed? It appears your VB application is read/writing directly to UV files directly and this is where you're having issues? Is it corrupting your UV file in the process? You vaguely mention you have rebooted your AIX server. Is that correct? Do you use dynamic files? What version of AIX, UV and UniDK are using? It seems like you've already checked the UniObjects and Unirpcd logs - have you check the UV errlog too? Anything interesting in that? Do you have separate server for testing/development or DR that you can: 1) test this same client software & your UV application/UniObjects? 2) restore (using your backups of your DB, source & object code + *very importantly* the UV home directory) your production data to and re-test the UniObjects-based app? Objective: determine if the issue is 1) client application is at fault, regardless of the target server it is communicating with or 2) database or application issue (rather than a client one). Other things to try: 1) write a simple UniObjects app (Win32 or Java versions) to read/write to the same file 2) a *completely clean* install the VB6/UniObjects app. This should be a clean PC which has never ever had the client application or UniObjects installed before. If you site has a "standard desktop configuration", then you should be using that or perhaps use a PC that is "non-standard". Have you rolled a new firewall or VPN client or similar network-invasive type application recently? Objective: 1) determine if it is UniObjects issue or not 2) determine if the problem is desktop PC or not (the latter by using a non-standard build PC). I have seen strange things happen with the U2 API before. So capturing the output from your UniObject sessions is a good one. If you have the code to your VB application - you can get it to turn on a COMO file. Given it a unique name for each session or user-ID (maybe the UNIX process ID too - eg., myuserid-date-PID.como) If your VB code is calling (directly or indirectly or dependent on some initialisation code) host-based BASIC subroutines (or indeed any cataloged referenced program) check if these have changed and re-catalog them all, regardless. I have seen "go away" after re-cataloging code - both at TCL invocation level and via the APIs. Good luck! Regards David ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
