Emerson Exchange 365

• Not Answered

Error : " Version Control was unable to create the SQL files needed to execute this operation".

Dear All,

We are trying to backup the database system using BackUp & Restore from DbAdmin. We get attached error while backup :

Error : " Version Control was unable to create the SQL files needed to execute this operation".

We tried taking remote access of Pro+ and also on physical Pro+ but still having the same error.

Login is as follows : DeltaV System : Administrator, Windows : Administrator.

Has anyone encountered similar kind of problem before if yes please kindly share the possible reason for having this error and its resolution.

Thank you.

• Database Administration Error.jpg
• View
• Hide

Ashish P

• 27 May 2014 3:21 AM
• Cancel

5 Replies

• Niklas Flykt

  

  • 27 May 2014 5:41 AM

  Hi,

  I have some recollection that you have to dissable version control to make the backups. ? . look in the upgrade instructions and see version control, there might be something about it..

  EDIT: The Backup and Restore tool can only run when no users are logged on to the database. This may make it impractical to use the Backup and Restore tool frequently.

  Have you checked that you do not have any e.g. terminal server logons at the same time.. use the tool under the DV folder and take a look..

  Niklas Flykt 

  Klinkmann Oy
  

  Key Account Manager safety products

  nikfly@gmail.com

  • Cancel
• Niklas Flykt

  

  • 27 May 2014 5:54 AM

  In reply to Niklas Flykt:

  

  Hi here are some instructions from BOLS..

  Backing Up the Version Control Database

  When you back up the DeltaV configuration database using the Backup & Restore tool, the Version Control database is also backed up, provided that the Version Control database is in the default location.

  If you want to perform a backup without backing up the configuration database or you want to back up the Version Control database to tape, you must perform a backup of the Version Control database through the SQL Server Management Studio. Be aware that when you use SQL applications to restore the database, the backup copy of the Version Control database will overwrite the current Version Control database resulting in the potential loss of Version Control history for your DeltaV configuration. In addition, you must run the Synchronize Database Utility in the DeltaV Database Administrator application to ensure that the latest configuration items in the Version Control database are identical to those in the configuration database.

  Follow these instructions to back up the Version Control database with the SQL Server Management Studio:

  1. Log in to the ProfessionalPLUS workstation as a DeltaV Administrator and as the Windows administrator.
  2. Close all the DeltaV applications.
  3. Use the SQL Server Mangement Studio database backup function. Documentation for this utility is available in the SQL Server online help. The Version Control database is named VCAT_databasename.
  4. Restore database using the SQL Server Management Studio.

  Note Backing up the Version Control (VCAT) database to a destination drive that is not the SQL database's drive requires the MSSQLServer and SQLAgent services to have access to the destination machine to perform the backup. In this case, the service accounts must be modified with the Service Control Manager. The accounts must be changed from the default of SYSTEM to a Windows account that has access to (permissions on) the destination machine (which must have a share) and is in the Administrators group on the DeltaV machine. An example of such an account would be the DeltaVAdmin account if the destination machine is running DeltaV software or if the destination machine has granted DeltaVAdmin access to the resource. Refer to Modify SQL Services Logon for more information.

  ---

  Modify SQL Services Logon

  In order to back up the  VCATdatabase to a destination drive that is not on the SQL database machine, it may be necessary to modify the SQL services service logon. Refer to Backup/Restore for more information.

  To modify the logon, perform the following steps:

  1. Log on to the SQL database machine (the source machine) as the local administrator.
     (To configure service startup, you must be logged on with a user account that has membership in the Administrators local group.)
  2. Select Start | Settings | Control Panel | Administrative Tools.
  3. Double-click Services.
  4. Select the named SQL Server instance, SQL Server (MSSQL Server).

     Note There can be other named SQL Server instances depending on what DeltaV functions or other applications are installed. For VCAT, select SQL Server (MSSQL Server).

  5. Right click and select Properties.
  6. Click the Log On tab.
  7. In the Log on as section, click the This Account: dot.
  8. Click the Browse … button to browse for the account. The account must already exist in Windows User Manager.
  9. Enter the name and click Check Names.
  10. Click OK if the name is found.
  11. Enter the password for that account on the Log On tab.
  12. Repeat the process selecting the SQLServerAgent service.

  Use the following table to determine the type of account to use and what the password must be.

  If you are backing up to:	MSSQLServer and SQLServerAgent Services Account log in as:	The destination machine:	Security access on the destination machine:
  a computer on the same domain	a domain account	uses the DeltaV domain account	The DeltaV domain account must have write access to the backup destination.
  a computer on a different domain with a domain trust relationship	a domain account	uses DeltaV domain account Note Grant access to remote network and directory to the DeltaV domain account.	The DeltaV domain account must have write access to the backup destination.
  a computer on a different domain without a domain trust relationship	a local or domain account	must have a local account with same name and password	The local account must have write access to the backup destination.
  a computer in the same or another workgroup	a local account	must have a local account with same name and password	The local account must have a backup destination.

  The destination (where the backup will be written) must be a shared device and the MSSQL services logon account must have Change permission to the destination folder.

  To configure the share, perform the following steps:

  1. Go to the destination machine.
  2. Select the drive or folder where the backup will be written and right click.
  3. Select Sharing...
  4. Select Shared As and provide a share name.
  5. Set the User Limit.
  6. Click Permissions.
  7. Click Add and select the MS SQL services user account (the one that MSSQLServer and SQLServerAgent are using for logon on the source machine).
  8. Select Type of Access as Change.
  9. Click OK until all dialogs are closed.

  For more information on configuring sharing, refer to the Windows help system.

  To set the permissions on the backup folder, perform the following steps:

  1. Select the folder where the backup will be written. This can be a subfolder of the share.
  2. Right-click and then select Properties.
  3. Select the Security tab.
  4. Click the Permissions button.
  5. Set the MS SQL services user account (the one that MSSQLServer and SQLServerAgent are using for logon on the source machine) to be listed with Change access. The account needs the ability to read from that folder, write to that folder, and create new files and folders in that folder.
  6. Click OK until all dialogs are closed.

  For more information on permissions, security, and access type, refer to the Windows help system.

  Niklas Flykt 

  Klinkmann Oy
  

  Key Account Manager safety products

  nikfly@gmail.com

  • Cancel
• Rachelle McWright

  

  • 27 May 2014 4:51 PM

  In reply to Niklas Flykt:

  Hello Ashish~

  Copying the post below from Youssef for your reference. This is posted in the Main DeltaV forum, if you care to respond or ask additional questions. Here is the link: http://community.emerson.com/process/emerson-exchange/systems-solutions/deltav/f/50/t/3743.aspx 

  Thanks!

  Rachelle McWright

  365 Community Manager

  ____________________________________________________________________________________

  Youssef.El-Bahtimy

  Posted by Youssef.El-Bahtimy on 27 May 2014 5:09 AM

  10.100.1.144

  I seem to recall this having something to do with the absence, lockout, or otherwise disabling of the deltav sql admin account. In SSMS make sure the DVSQLADMIN (i think) account is present and not locked .

  Youssef El-Bahtimy | Systems Integration Technologist

  PROCONEX | 103 Enterprise Drive | Royersford, PA 19468 USA

  Proconex Office: 610 495 2970 | Cell: 267 275 7513

  Youssef.El-Bahtimy@ProconexDirect.com

  Best Regards,

  Rachelle McWright: Business Development Manager, Dynamic Simulation: U.S. Gulf Coast

  • Cancel
• Ashish P

  

  • 28 May 2014 1:50 AM

  In reply to Rachelle McWright:

  Dear All,

  Thank you for your replies.

  I have check the folder permissions and Security settings as mentioned by Niklas Flykt, but everything is set properly. We tried to compare the settings with Other Systems and settings and permission are all set properly.

  I have also checked for details given by Youssef.El-Bahtimy  but the DVSQLADMIN account is already present and enabled.

  We are still trying to search for other possible reason's. In case if you think we might have left out something then please kindly let me know.

  Still searching for possible reasons for having above problem. All the help will be appreciated.

  Thank you for your time and support dear Colleagues.

  Regards,

  Ashish P

  • Cancel
• Youssef.El-Bahtimy

  

  • 28 May 2014 2:37 AM

  In reply to Ashish P:

  Have you looked at both the Windows Application and System logs in addition to the SQL Server logs for errors and warnings?  

  Regarding your system, is this a new installation, have you just enabled VCAT, or do you have a well established system with VCAT that has just started showing problems?

  Does your database name contain a "&" ampersand or other unusual character?

  Also consider enabling Failure auditing in the local or domain security policy so that if access is being denied for whatever reason, the Windows security log will show it.

  • Cancel