FactoryTalk to SQL

Julien404 · Jul 7, 2022

I'm trying to get some data into my SQL database and it seems like FactoryTalk (SE) is not able to write in it. It did successfully create the tables inside of it though. I made a button to run the command DataLogOn for the model I made and I get the message ''Unable to process the following command : DatalogOn test2''. It is my first time working with SQL stuff so any help is appreciated

Mikofi · Jul 7, 2022

With a comprehensive picture of production status across entire lines and processes, FactoryTalk® View Site Edition (SE) lets you monitor and control manufacturing at all levels, from a single operator station up to distributed server/client, multi-user applications.

Steve Bailey · Jul 7, 2022

Trying to answer a question with a marketing blurb??? Mikofi, please explain to me why I shouldn't delete that response as spam.

drbitboy · Jul 7, 2022

Steve Bailey said:
Trying to answer a question with a marketing blurb??? Mikofi, please explain to me why I shouldn't delete that response as spam.

LOL. Maybe it was sarcasm by @Mikofi?

Julien404 · Jul 7, 2022

For anyone who might stumble on this thread, heres how I fixed it :

- Open the SQL Server management Studio
- In the object explorer : Security/Logins/Right click/New Login
- Click on search and type "LOCAL SERVICE" and then ok
- Do the same thing again but for the user ''SERVICE''
- Double click the users and give them the server role ''sysadmin''

Now it should work.

When you test the connection or write the tables you connect to the database as local user, but when FTV tries to connect it does it as a service.

This error code is also related to that : unable to access odbc data source

phuz · Feb 3, 2023

Julien404 said:
For anyone who might stumble on this thread, heres how I fixed it :

- Open the SQL Server management Studio
- In the object explorer : Security/Logins/Right click/New Login
- Click on search and type "LOCAL SERVICE" and then ok
- Do the same thing again but for the user ''SERVICE''
- Double click the users and give them the server role ''sysadmin''

Now it should work.

When you test the connection or write the tables you connect to the database as local user, but when FTV tries to connect it does it as a service.

This error code is also related to that : unable to access odbc data source

Was hopeful, but this did not solve it for me.
I created the 32-bit ODBC connection by launching the app from the SysWOW64 folder, successfully. Then used that connection in the datalog model, and it successfully created the tables, but I still get this error when attempting to start the datalog from the command line:

Unable to process the following command: DatalogOn someDataLogName

FWIW, it behaved the same whether I used a system DSN or a file DSN.

glennz · Feb 3, 2023

phuz said:
....but I still get this error when attempting to start the datalog from the command line:

Unable to process the following command: DatalogOn someDataLogName

FWIW, it behaved the same whether I used a system DSN or a file DSN.

I believe the Command Line is case sensitive. Try "DataLogOn" instead of "DatalogOn"?

Operaghost · Feb 3, 2023

Commands are not case-sensitive.

I had trouble years ago using the ODBC format with MS Access. We used Access for some classroom stuff as it was easy to use. I don't remember all the details, but it generated a similar error. In our case it wouldn't let us restart a log that had been stopped. So it did log data, until we stopped it.

We ended up switching to SQL Server Express and once we performed the step Julien404 mentioned (there is a Tech Note) everything worked for us.

OG

phuz · Feb 4, 2023

Correct, they are not case sensitive.

Did some looking in the Tech Notes, and it says if FT View Studio and the HMI Server are two different computers (which they are), make sure the DSN exists with the same name on both computers. I added the same DSN to the HMI server (32 bit, of course), and still end up with the same error.

sigmadelta · Feb 4, 2023

One thing to make sure if is that port 1433 is open on the firewall - this is the default TCP port for SQL connections. This is important for the computer hosting the database and accepting incoming connections.

phuz · Feb 4, 2023

If the port wasn't open, it wouldn't make the connection and definitely wouldn't be able to create the necessary tables.

sigmadelta · Feb 4, 2023

OK, I didn't quite get whether you were creating the tables locally on the SQL server itself, or from the remote computer.

phuz · Feb 4, 2023

sigmadelta said:
OK, I didn't quite get whether you were creating the tables locally on the SQL server itself, or from the remote computer.

No, I let the datalog model do it natively.
I think I found a resolution. When I first set up the System DSN on both, I used windows authentication (domain-level, same credentials). Now, I created another user within SQL and used that for the SYSTEM DSN credentials on both; and I also checked the "Login Required" box in the datalog model. It started without error now.

sigmadelta · Feb 4, 2023

yeah, I always use SQL Authentication as opposed to Windows Authentication when the SQL Server is on a different computer than the application.

FactoryTalk to SQL

Julien404

Member

Mikofi

Member

Steve Bailey

Lifetime Supporting Member + Moderator

drbitboy

Lifetime Supporting Member

Julien404

Member

phuz

Member

glennz

Member

Operaghost

Member

phuz

Member

sigmadelta

Member

phuz

Member

sigmadelta

Member

phuz

Member

sigmadelta

Member

Similar Topics