My Open API, Windows based app, can successfully open and 'get' properties of FMBs stored in the Windows file system. However, it fails to load the FMB when the FMB resides on a networked Unix server. The same FMBs on Unix can be opened by the Windows based FormBuilder (over the network). I can copy the FMB down to Windows and without re-compiling the FMB, my Open API app can 'load' the FMB and 'get' all the properties. What suggestions can you give for debugging / resolving this? I need to be able to 'Load' the FMBs (through the Open API), that reside in the Unix file system, from Windows.
What you are doing and how exactly you are doing it seems quite unclear to me. However, anytime Unix is involved my first suggestion is recommend carefully looking at case sensitivity and file permissions.
Michael, thanks for your question. I have a C++ Windows app that links to and makes calls into the Forms Open API (DLLs). The call to 'd2ffmdld_Load' fails when the target FMB resides in the Unix file system. It does not fail when the FMB resides in Windows.
Further, the Windows installed FormBuilder IDE is able to open and load the FMB when it (the FMB) resides in the Unix file system. The permissions on the FMB in Unix are the same for FormBuild IDE as my App.
What additional clarity would help you understand my question?
Generally, this is why we will tell you that accessing net shares is not supported and in places where it might even be supported, we would still suggest that it is not recommended. Accessing via net shares (especially through Windows) is often problematic. There are various performance and connectivity issues that, unfortunately fool you into believing that the product you are using is flawed when the problem is really a connection issue with the share.
In your case, because you are not exactly using an Oracle product (initially), Oracle can't offer much anyway, but I would recommend against using shares whenever possible. If you need to access a file, copy it locally first, perform whatever task on it, then return the updated file to its origin. This method protects you from things like net failure and instability as well as the performance issues associated with accessing files remotely.