connect error using .net 2.0 provider

[zhangmb]

Hi,

I am trying to connect to a remote Ingres installation using .net 2.0 provider as below.

//open connection using .net 2.0 provider .
IngresConnection conn = new IngresConnection("Host=192.168.1.11; User Id=student; PWD=12345; Port=II7; Database=demodb"),
IngresCommand command = new IngresCommand("select * from road", conn)
conn.open();

the error message is : ex = {"User authorization check failed.\n Your user identifier was not known to this installation.\n Contact your system manager for further assistance.\nThe connection to the server has been aborted."}

student is an normal user , so error occured. But if I use $ingres or OS administrator account, connection is ok.
why? does it only administrator account can connect ?


Thanks

--zhangmb

[kschendel]

Is "student" a valid Ingres user in the remote Ingres installation? The process of installing Ingres adds $ingres and administrator as Ingres users automatically; other users have to be defined to the Ingres installation by hand. You can use the "create user" sql statement, the accessdb utility, or visual DBA to define users. I'm pretty sure the process is explained in the DBA manual.

[zhangmb]

hello, carl.
yes. I create "student" with visual DBA, and I can connect "II" installtion use "student" with openAPI or by "sql -ustudent demodb".

[lunbr01]

The error message you are getting is indicative that the user ("student") is defined as a valid OS user on the remote server machine but is not defined as a valid user to Ingres on that system. This is exactly what Karl was asking about and what you verified was OK, so it is surprising that it is not working for you. I ran some tests to confirm this and that was the only situation I could get to reproduce that particular error. The user does not have to be set up with any special privileges. The only thing I can think of that might be the problem is that you are not connecting to the same Ingres server remotely from .Net that you connect to when using OpenAPI or terminal monitor locally on the server. There are several ways to confirm this. If you have an Ingres client on your .Net machine, try accessing the server with terminal monitor as follows: "sql -ustudent @192.168.1.11,tcp_ip,II[student,12345]::demodb". If your .Net client machine doesn't have an Ingres client installation to run terminal monitor from, a couple of other options are to:
1. On the server, bring down the Data Access Server (DAS) as follows: ingstop -iigcd
Then, you should get a different error when trying to connect from your .Net application (namely, a communications error exception).
2. Connect to database iidbdb instead of demodb with one of the users that works (like administrator) with your .Net application. Verify user "student" exists in the Ingres installation by running the query "select name from iiuser" and check the results.

If everything still looks OK, I could give you some tracing to do in the Ingres server to help diagnose the problem.

Regards,

Bruce

[zhangmb]

Thank for your help.
I try "sql -ustudent @192.168.1.11,tcp_ip,II[student,12345]::demodb" as you suggested and the answer is as follows:
1. if student is OS administration，it is ok。
2. if student is OS normal account and Ingres normal account at the same time，then the terminal prompt: Please enter your password:. Then I input the password, and it passed.
3. if student is just an Ingres normal account, not a OS accout, then error message is: E_LC0001 GCA protocol service (GCA_REQUEST) failure. Internal service status E_GC000b -- Login failure: invalid username/password.

why? Does an user should be OS account and Ingres account at the same time?

I debuged and found that, if user is OS administration, then in function scs_initiate(scsinit.c), the scb->scb_sscb.sscb_state will be set to SCS_INPUT, and passed. But, if user is an ingres nomal account, scs_initiate will call the function scs_dbdb_info, and in scs_dbdb_info it will judge ust.du_pass, and ust.du_pass is not null(so user is password protected), then it will check the ics_rupass(check if user specified an initial password), but ics_rupass is null, and then it set the ics_uflags |= SCS_USR_RPASSWD and return to scs_initiate and then return to scsqncr.c, the scsqncr.c then prompt for password. But because no terminal in .net program, so no prompt for password, and then scsqncr.c will call scs_check_password with NULL password, failed in the end.
I think that ics_rupass should not be null, then it can compare with the ics_srupass, and passed if matched, but it is null actually. I don't konw what happed.

Help! Thanks!

[lunbr01]

It sounds like you set up the user in Ingres with a password -- what is referred to in Ingres as a DBMS password. Typically this is not done. While it is a requirement to define the user to Ingres, it is not required to set the user up with a password in Ingres (since the user will have already had to pass through OS user/password authentication). Make sure in VDBA to NOT enter anything in the "Password" and "Confirm Password" fields on the "Create User" screen. If you do, the DBMS will send back a prompt asking for the password after it has verified that the user is defined; this will fail unless the keyword Dbms_password was supplied in the connection string.

The reason the OS administrator worked fine is because it is automatically set up as an Ingres user WITHOUT a DBMS password.

Regards,
Bruce