TO pass login userid and password as parameters from Navision into .net Dll

hi,

I have a issue in which i have to pass the Navision Login Userid and password from navision to .Net Dll. As parameters.But my problem is i am not able to get the password.

Can anyone suggest how can i get login password in Navision.

Regards

renjita

With Windows Authentication you don’t even need to know user’s credentials at all - Win manages access rights, especially if the other side is .net based. DB authentication may be a problem here - but which one do you use?

hi,

I am Using SQL SERVER 2005 DATABASE.But Without passing Password into dll i will not be able to get the data as SQL Authentication is done for userid and password.

regards

renjita

Is the DLL yours? You might add the below:

Try
connection.ConnectionString = “Server=NAVISION; Database=YourDataBase; Integrated Security=SSPI; Type System Version=SQL Server 2005”
connection.Open()

Catch expSql As SqlException
End Try

But How would we get connected to database if we donot specify password.

I am using the connection string as

Here i have hardcoded the userid = pa and and Password = goal;

SqlConnection con =

new SqlConnection(@“server=WIN\SQLEXPRESS;database=Dynamics;uid=pa;pwd=goal;”);

SqlDataAdapter daEmpNo = new SqlDataAdapter(“SELECT distinct documentNo from [” + companyName + “$tempSlip]”, con);

Read my previous post - the answer is there already (for Windows Authentication)

connection.ConnectionString = “Server=NAVISION; Database=YourDataBase; Integrated Security=SSPI; Type System Version=SQL Server 2005”

or using your style:

new SqlConnection(@“server=WIN\SQLEXPRESS;database=Dynamics; Integrated Security=SSPI”);

added:

to make it straight & clear - you DON’T need to include either “uid=” or “pwd=” if you have “Integrated Security=SSPI”

hi,

Integrated Security = “SSPI” is not working here.

I have Sql Auntentication Only for that database.

Regards

Renjita

Well, then it’s a problem - passwords are stored in SQL in encrypted form, you can’t get them programmaticaly in usable form (IMHO MSSQL ver.6.5 was the last one including special function which returned dechipered user’s password, it’s removed now).

Do you have some serious reasons not to change from Database to Windows authentication? The latter is more “advanced” and easier to use anyway…

hi,

Sql Authentication is must. We need to create roles for each logins.

Is it possible to get navision table data directly for web service without connecting to SQL Server.

Do we need the same connection string used earlier if we are using SQL Server database for data pulling using web services,

Regards

renjita

If you mean SQL Roles - where do you see the reason you can’t create these for Windows Users?

These are absolutely unlinked things - method of authentication is separate from what you do with the User accounts further, including granting them different rights, assigning roles etc. etc.

hi,

The Integrated Security = SSPI in DLL Connection string is working fine now.

But there is another issue

When i write the Integrated Security = SSPI in Navision C/AL code it is not working.Showing Connection error.

But i have written Persist Security Info=FALSE;’ instead of Integrated Security = SSPI , then it is working fine.Will there be any issue regarding securtiy of data or any other type while using Persist Security Info=FALSE;’

the code is as follows:

CREATE(myConnection);
CREATE(myRecordSet);
sSQL:= ‘SpUpdateEmployee’;

myConnection.ConnectionString :=
‘Driver={SQL Server};Server=WIN;Database=Development;Persist Security Info=FALSE;’;

myConnection.Open();

Is it OK ?

Once more - there is no difference, HOW you authorise access, by means of which method. These are only different ways of “unlocking the door”, once you are in, you are treated the same.

Additionaly, all security issues are managed inside your .dll (it creates connection to SQL, as I understood). And, when this .dll is called, it’s done in current user context - if the user is not authorized in SQL, your .dll simply won’t connect. BTW, you should handle this exception in your .dll (i.e. with Try/Catch structure), otherwise occasional call to .dll by unauthorised user will end up with unhandled error and crash…