Finance | Project Operations, Human Resources, ...

Integrated Security is required Error When using SQL Authentication in Connection String

(0) Share

Report

Posted on by Vaidh

I'm Getting the following error when creating transaction using eConnect in GP, with SQL Server Authentication in connection String.

Integrated Security is required. \r\n Please ensure that the ConnectionString input parameter is valid.\r\n Examples:SQLCLIENT Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=TWO;Data Source=MySQLServerName \r\n Examples:SQLOLEDB Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=TWO;Data Source=MySQLServerName

I'm using GP 2016, and eConnect 16.0

Categories:

Microsoft Dynamics GP

I have the same question (0)

All responses (3)

Answers (0)

Derek Albaugh Microsoft Employee on at

Like (0)

Report
Copy link

Link copied!

An example of a connection string I've used with eConnect is here:

"data source=SQLInstanceName;initial catalog=TWO;integrated security=SSPI;persist security info=False;packet size=4096"

The data source would be the SQL Server instance name. If you have a named SQL instance, enter the entire name such as ServerName\SQLInstanceName.

The TWO would be whatever company database for GP you're running against.

See if this example doesn't work for you.

Thanks

Was this reply helpful? Yes No
Vaidh 60 on at

Like (0)

Report
Copy link

Link copied!

I dont want to use : Integrated Security=SSPI

Was this reply helpful? Yes No
Suggested answer

Beat Bucher GP Gee... 28,058 Moderator on at

Like (0)

Report
Copy link

Link copied!

Hi Vaidh,

Why don't you want to use Integrated Security for the eConnect connection ? this is the most secure way of establishing a data connection to a SQL server.. Anything else is unsecure and could be just looked up by anyone who could access the application or the data connection..

I typically mention as example the Excel workbook data connection to Dynamics GP data.. you can use a SQL user for the authentication string, but then anyone who has access to the Excel workbook would be able to lookup that SQL user (which can't be a GP user by the way, as the pwd is encrypted on the SQL side).

Using SSPI allows for secured access control on the SQL server data side, since you can specify which user or group has access to which data.

Was this reply helpful? Yes No