One common solution design method that I’ve both observed being used by others and that I use myself is to organize my solutions and projects using the SolutionName.ProjectName naming convention. While it provides no functional value, this naming convention is a way to designate the relationship of your assemblies to the solution as well as to define visually the separation of concerns as seen below.
As you can see from the image above, The solution name is “SportsStore” which is prepended to each of the contained projects as a form of convention. This has always worked well with Microsoft SQL Server, however I have found that it presents an issue when coding to an Oracle database.
Upon creating a new project and preparing to connect to the backend, I was met with the following error:
I first found myself at a stop because I knew that the code was correct and the unit tests against the mocked collections passed. So I turned to Bing to search for a solution. I did find an interesting article explaining the issue which led me to the conclusion that Oracle has “limitations?” as it applies to directory paths and thus the use of special characters such as periods and parenthesis when naming your projects. According to Oracle Docs:
ORA-06413 Connection not open.
Cause: Unable to establish connection.
Action: Use diagnostic procedures to ascertain exact problem.
So as it turns out, if the calling executable resides within a path containing too many periods (one, in addition to the .exe) or parenthesis, then the connection will fail to open.
I did not document a complete list of invalid characters because it’s not likely that I would name a project using anything other than periods as delimiters, but do be aware that this “issue/feature” does exist when connecting to an Oracle database. In the end, I guess I’ll have to use another project naming convention. While I’m not so fond of the “SolutionNameProjectName” convention, maybe it will have to suffice for the environment at hand.