We have an x-files problem with our .NET application. Or, rather, hybrid Win32 and .NET application.
When it attempts to communicate with Oracle, it just dies. Vani
You should probably see if you can reproduce the problem it with a simple application that only tries to open a connection to Oracle. That way you can be 100% sure that the problem is with OracleConnection or the Oracle driver and not with your own code.
Here's what I would do. First, TRIPLE-check that you're seeing the behavior you think you're seeing. I can see this happening the other way around by not using System.IO.Path to concatenate paths, but not like you're seeing it. Triple-check that the file permissions make sense.
Next, download Filemon from MS and watch what's happening on the filesystem as your program hits these troubled spots. You can filter out specific file activity (removing your anti-virus file activity, for example) to make everything look a bit cleaner while you do this. Look for file access errors using FileMon for both the success case and the error case for your program. That should point you to what file's being accessed and causing the problem. For example, if you see a FILE_NOT_FOUND
error accessing a nonsense filename, you can be assured that you or the vendor are doing something wrong, possibly leading to your problem...
You should get a medal for perseverance for that !.
"Exactly what XPO does now I don't really know, but if I dropped this table, and recreated it with the right case, using double quotes around all the column names to get the case right, the problem doesn't crop up.
Exactly where the space in the folder name comes into this, I still have no idea"
The issues I get with spaces in names is that they generally interpret the bit before the space as the name and the rest as a parameter. If that is the case, then with the plain name it can see "C\Temp" and it is a directory. With the spaced name, it gets "C:\Program Files", looks for "C:\Program" and that doesn't exist. It would fail, for example, to overwrite "C:\Temp" but would succeed in writing "C:\Program". Wonder whether it would still fail with "C:\Program Files" if there is a file or directory called "C:\Program"
I´d suspect the oracle client to be honest. Had a problem which was similar in it´s frustrating nature.
If we installed on 64 bit machines the client would stop at start when connecting to oracle even though the app is 32 bit. We eventually tracked it down to the fact that a certain oracle client (Ora 10 had a problem with brackets in the path so a program running under program files would work under program files (x86) caused the crash. Updating the machine to use the 11G client fixed the problem but there were also some patches available from metalink which are not directly available. Whats strange in your case is that you get no exception but the behaviour of moving the application to a new folder fixes the issue in a similar way so it may be related.
ORA-12154: TNS:could not resolve the connect identifier specified or ORA-6413: Connection not open.
Useful links http://blogs.msdn.com/debarchan/archive/2009/02/04/good-old-connectivity-issue.aspx
Details from Metalink below.
Metalink Bug 3807408 Cannot externally authenticate user with quote in username
Description If an externally authenticated username contains a '(',')' or '=' then the user cannot be authenticated. Additionally if a program name / path contains these characters it may not be possible to connect . eg: Windows clients installed in a directory "C:\Program Files (x86)" fail to connect with ORA-12154: TNS:could not resolve the connect identifier specified
The hallmark of this problem is that the Net trace (level 16) shows the problem character/s replaced by a "?" in the trace.
Workaround For the authentication problem: change username, or do not use remote OS authentication for those users
For the program / directory issue: change the program/directory name