Progress 9.1C ODBC from .NET

nmercer

New Member
Hi,

I'm wondering if anyone has had any success with accessing Progress from a .NET application?

I'm currently trying using Progress 9.1C and Merant DataDirect Connect 3.7 - unfortunately upgrading the Merant drivers is not an option at this time. If I set up a DSN I can connect from other apps, e.g. Excel, but when trying from my VB.NET app I get "Optional feature not implemented" and "PROGRESS error returned with no associated message: RC = -1, SQLCODE = -1, SQLSTATE = ""."

I've tried the Progress SQL92 driver, and have slightly more positive results. I'm able to connect to the database, but it gives me an "Access denied" message when trying to pull any results. We use Syteline, so I'm reluctant to make changes to the database without understanding what impact that will have on Syteline first.

Anyone able to offer some useful advice?

Thanks,

Neil.
 
.NET Progress

Hi,
Yes, I connect to progress 9.1D using DataDirect-Technologies 3.60 SQL92 driver from C#. It actually works quite well, most of the time. I am getting the same error right now on a system that has been running fine. Here are the most common causes I find (I am running this on about 5 different progress servers). #1 not enough user licenses, but this usually tells you deep in the error message
#2 you try to connect multiple threads too quickly, I have hit this myself and use simple Sleep calls to get around it
#3 network congestion or name resolution, though I don't really believe this is the problem. I am currently having this problem with only 1 server. I will post again when I find the answer. If you need any advice, help, or sample code email me.
-Dan
 
ASP Net applications log users into your web server under a different account than classic ASP. Typically, classic ASP will use the IUSR_WEB account, and ASP.NET will use the ASP_NET account. You need to make sure that the ASP_NET account has access to the folder that the progress driver is located in.
 
I've tried the Progress SQL92 driver, and have slightly more positive results. I'm able to connect to the database, but it gives me an "Access denied" message when trying to pull any results.

You need to grant SELECT permission to the user you are connecting with.

Here the KB Entry on it :

Granting permissions on tables to regular users:
In the SQL-92 database, as well as in other SQL databases, regular users do not have access to database objects until the proper permissions are granted to them.
In order to grant privileges, connect to the database using a DBA account. In this case, use the default DBA that is the user who created the database.

Perform the following SQL statements to grant select access on the pub.customer to user1, and full access to the pub.state table to all users:

- grant select on pub.customer to user1;
- grant all on pub.customer to user2;
- grant select on pub.state to public;
- commit;

The revoke SQL statement can be used to revert permissions given by the grant statement.

Add a commit statement to make the database changes permanent. In sqlexp, the AutoCommit option is false by default and if or when the user disconnects, the changes done on the database are rolled back.

Notice that permissions can be granted to users even though the users have not been explicitly created.
Validation of user access (when no entries exist in the _user table) are based on operating system user accounts.
When a user requests a login and no _user table entries exist then the database server engine will query the operating system user accounts to see if one matches the user name and password being submitted for login.
If a user name and password match at the Operating System level then the user is logged into the database and any defined permissions (grant statements made for that user or to public) are allowed.

NOTE: The SQL-92 Guide and Reference book provides additional information on the GRANT and REVOKE statements.

Try the following SQL statements and connect as user1 first and then user2:
select * from sysprogress.sysdbauth

Users (user1) and (user2) should be able to access this table because it is public.

Both user1 and user2 should not be able to access this table because it is not public:

select "_userid", "_password", "_user-name" from pub."_user"

Both users should be able to access records in pub.customer:

select * from pub.customer

User1 and user2 should be able to access this table because it is public:

select * from pub.state

Only user2 should be able to update the pub.customer table:

update pub.customer set creditlimit = 70000 where custnum = 10

User1 should get an error message:
 
Back
Top