Old School Error

TestCSLA posted on Thursday, May 15, 2008

I use CSLA 3.5 and I'm having ZERO problems. However, I've got an OLD program using CSLA 1 - and in moving that program to another machine I'm running into a problem.

My problem is ONLY when I attempt to use remoting. Basically I'm not hitting the database at all. I have some old notes and made sure that I unchecked "Enable Integrated Windows Authentication" in IE 6. I also made sure I selected "Anonymous" in IIS.

My code breaks right after in the Dataportal after the line:
MPortal = New Server.Dataportal

The DBA has confirmed I'm NEVER hitting the database. Now this code hasn't changed in about three years so I know its not the code, but some type of setting.

I can hit the Oracle database using TOAD - so I know my tnsnames.ora file is correct. I would like to know how CSLA finds the .ora file since I don't reference it anywhere in my code (could that be the problem - some type of Oracle setting?).

If anyone can help me out with setting to check concerning:
1) References (all seem to be set correctly)
2) IIS Settings
3) Oracle settings
4) Long shots
5) Internet Explorer

Thanks in advance.

Yang replied on Thursday, May 15, 2008

I believe oracle will look for the tnsnames file in the Network\Admin folder found in the path specified by ORACLE_CLIENT user environment variable. If you are running IIS as a system account, you are better off by overwriting this by creating a TNS_ADMIN system environment variable that is the absolute path to your tnsnames.ora file.

Good luck!

TestCSLA replied on Thursday, May 15, 2008

I can connect to Oracle using Oracle's SQL Developer. My problem is CSLA isn't getting the proper connection string. Do you know where I can set a breakpoint in CSLA to see exactly where its trying to obtain the connection information from the tnsnames.ora file?

Yang replied on Thursday, May 15, 2008

Are you using the connectionStrings settings in your app.config/web.config? Are you using ODP.NET or Microsoft's oracle provider?

It is not possible to set a breakpoint to figure out what it is getting from the tns names but you should be able to set a breakpoint to where you define and instantiate the OracleConnection object. The connection string can be passed to the constructor of the OracleConnection object. Or you create the OracleConnection using the parameterless constructor then assign a connectionString afterwards.

TestCSLA replied on Thursday, May 15, 2008

Yes, I'm using connection strings in web.config - which simply state to use a specific db in the .ora file.

Everything is going to the dbhelper just fine, but I don't think it is actually accessing the .ora file. Someone suggested to allow "EVERYONE" complete access to my Oracle/Ora92 directory. I'll tell you if that works.

I've run into similar problems in the past and they are always related to settings on the machine (specifically IIS or IE). I just can't figure out which setting on this machine is the problem.

Last bit of info that might be helpful - does it matter what version of DBHelper I'm using? About three months ago they updated all the Oracle DB's to 10.

Yang replied on Thursday, May 15, 2008

I am not familiar with the DBHelper but it should not be a problem. Have you updated the Oracle DB Driver in your IIS server machine? Although the driver of Oracle 9 should work still with 10. Can you post a stack trace of the exception?

Have you tried adding the TNS_ADMIN system environment variable? IIS user usually does not know where to find the tnsnames.ora. After adding this, you need to restart IIS for the change to take effect.

JoeFallon1 replied on Thursday, May 15, 2008

I supported Oracle for years with CSLA.

The only thing I had in my config file was:

I used Oracle tools to create SomeOracleService and then made sure I could connect using the ID and Pwd above. Then everything worked fine. I don't recall having anything try to read the tnsnames.ora file directly. The creation of the Service does that.

Joe

Yang replied on Thursday, May 15, 2008

Joe,

I am not familiar with your approach. We have been using Oracle for years too and the way we connect is to have a tnsnames.ora file that is reachable by the Oracle Provider. We use the same connection string as you specified. The data source is the one configured in the tnsnames.ora file. We are not reading the tnsnames.ora file directly. By setting the TNS_ADMIN environment variable, we are instructing the provider to get the tnsnames.ora from the specified location. The TNS_ADMIN is especially helpful when the user is a system user/IIS User.

Regards,
Yang

JoeFallon1 replied on Friday, May 16, 2008

Yang,

I think we are doing the same thing. The Oracle tools are installed on the server so that it can talk to the DB. The data source is configured in tnsnames.ora file using Oracle tools. Then prove you can connecto from that server to the DB using Oracle tools. Then the connection string should work fine.

I never had to do anything with environment variables though. Not sure about IIS permissions - I may have granted them so long ago I forgot about it.

Joe