Skip to main content

*** Will be cross-posting here and on ESRI community/geonet.*** 

 

I have an FME process that uses the SPROC's for versioned editing with the .evw views inside an FME SQL Executor...

-- Change to the FME version 
EXEC sde.set_current_version 'myFMEversion';
EXEC sde.edit_version 'myFMEversion', 1; 
-- DO MY THING HERE
EXEC sde.edit_version 'myFMEversion', 2; 
 

This has been working great in one database and running in FME Server under a service account.

 

Now, when I try and use it in another database, after creating a 'Public' version called 'myFMEversion', I can run it in FME Desktop successfully where I'm Admin on that DB. But when I run it in server which uses the service account, it fails with this error:

360	| Microsoft SQL Server Non-Spatial Reader: Query failed, possibly due to a malformed statement. Query Text `-- Change to the FME version 
361 | EXEC dbo.set_current_version 'myFMEversion''. Provider error `(-2147217900) Version myFMEversion not found.' 
362 | A fatal error has occurred. Check the logfile above for details 

 

'Version Not Found'? -- So it looks like the service account hasn't been granted the proper SQL privileges to use the stored procedures in my new DB. But what privileges are needed? 

Old and new DB's both have the version as 'Public' and owned by 'DBO'.

Hi @agelfert​ would you be able to provide the full log files from trying to run the workspace in both FME Desktop and FME Server? The permissions for the database only need to be on the User in the Database Connection that was setup within the workspace.

The only issue I could see here is if the Database Connection was not published to FME Server alongside the workspace and when the workspace is run in FME Server, it's using the wrong Database Connection - perhaps one that was already published to FME Server before the workspace.


@danminneyatsaf​ - Good thought.... I'm not sure I still have the logs but could try to replicate this when I have a moment. For the time being, my ninja work-around has been to grant super powers to the account in SQL which worked. But what you're describing would make sense!


Reply