This content has been marked as final. Show 13 replies
Along with the other questions you were asked, you might answer if all the users affected the same way or only one or some? Where is the destination where the files are to be written? If it is a network, then perhaps the user(s) don't have creation privileges in the directory or the directory itself needs to be created and they don't have that ability.
You might also look to see if the destination already contains copies of the files you are trying to get and these files are flagged as read-only.
We use SQL Server 2008 R2 Client to connect to the databases. The tables were created by the DBA using the DDL's created generated by the Studio IDE. Studio IDE is able to read the files from the SQL table as we see the resource details getting displayed in the IDE. We get an error message "An error occured getting the file <.....> when we try checking out the resources. We see the same error is displayed to all the users.
Studio is installed in my local machine and the SQL database is hosted in a server accessible via the network. The INI's are configured to write the files in my C: drive.
Edited by: Dhanraj on Jan 17, 2013 6:32 PM
I believe I have seen this before.
When the Documaker Studio tool is used to generate a DDL it is during the create new workspace wizard typically. When the Studio user process this studio also makes the appropriate and specific configuration files for the new workspace which match the selected DBMS, INI files (fsisys.ini and fsiuser.ini) and the deflib\*.dfd files and any other configuration files created.
Basically the MRL is configuration files and the external database stored resources.
In order to use this newly created workspace to push or pull resources to and from the library these configuration files have to be in place on any machine doing work on the MRL / workspace and considered part of the workspace, having the ODBC connection and workspace that does not match in configuration can lead to this error.
It is possible that since your tables were created by the DBA that your users don't yet have the right to update the table. I believe you said that if you ago into Studio that you can see the library list just fine. Yes?
And if you click on the Preview tab, can you see the resources displayed there? Yes?
If you right-click on the file from library manager, you will see "Read" as one of the options. Choose that instead of Check Out. Does that bring up the resource file or give a similar error?
If the Read does bring up the resource manager, that means you can retrieve the resources just fine, so I would guess that the error you see on check-out means your users were not given the right to update the table with the locked status.
If the Read does not bring up the resource and gives the error you mentioned before, then it is either that network rights - assuming your users are using the network as the sandbox; or it is a mismatch on the table definition as another user suggested.
Appreciate your inputs. Could you please briefly explain your suggestions on the INI files and the Database access. I was not able to completely understand the issue. Apologize for that. Initially when we were trying to create the workspace uisng 12.1 Studio IDE, the IDE was not able to access the tables. We added the instance name along with the table name in the INI files and from then on Studio was able to access the tables.
We use the ODBC drivers to connect Studio to the SQL table. The User-ID that we enter in the ODBC set-up has both read/write access to the database. We were able to view/insert the resources using the same id via SQL client installed in our machine. As Studio is configured to use the ODBC set-up created using the same id , I believe Studio should be able to read/write files from the tables.
When we try the read options in the "Library Manager" we don't get any response nor the error in the Studio. Do the DBA need to specifically grant any rights for the studio user id's (Our LAN-ID's) to enable us to read/write to the tables.
Hope this might help you..
When you run the Create New Workspace wizard in Documaker Studio and select your DBMS type it tries to deploy the tables through our ODBC connection.
If successful it will then create the workspace with some minumum resources and query for other info like Font Cross-reference file, etc. and when done you have a complete workspace which includes INI, DFD configuration files specific to your choice of DBMS type. This workspace and it configuration files (e.g. fsiuser.ini, fsisys.ini, deflib\carfile.dfd, etc.) are needed for access to the workspace properly.
If the wizard is unsuccessful (for reasons such as permissions, access, etc.) it will let you generate a DDL and pass it off to the qualified personnel but it expects you to either leave the studio running and continue from there or to re-run the create workspace to complete the task and configuration. If you stop at the DDL stage and don't complete the task but try and use internal defaults for the configuration files the resource may appear to deploy but they will not load upon studio preview or attempt by the publishing engine to process with them because the internal configuration does not use the appropriated datatype for the database. This situation would be classified as improper or incomplete workspace creation.
I suspect you hit this problem. Going back and configuring a workspace to just talk to the database is not appropriate and can have undefined results.
Hope this helps,
Can you see the resources in the Studio IDE from the Library resource list view when picking the 'preview' tab and highlighting resources, especially resources over 4K in size, larger resources or ones that it gives the error for. That is the first thing to check. If that is fine then your DBMS setup and Documaker configuration is fine and I was going down the wrong path.
It may be that the process of locking and checking-out resource, which includes creating a local copy on disk once it is locked in repository, is failing because it doesn't have permissions to write to the folder where Studio workspace is running from.
"An error occurred getting the file <.....>" seems to indicate permission problem. I believe the process includes checking to see if the file exist first in the workspace location too so could be initial check-out process can't read the location or perform operations it needs to in order to lock the resource.
We are unable to preview the resources in the Library Section. We don't get any error message when we select the resource and click preview. We connect to the SQL database via ODBC and the ID used for configuring the ODBC has both read/write access to it.
Let me know if we would need any other access to be provided on the tables/databases to load the resources.
Are you able to perform extract/import in this library using studio (and/or scripts using the current INI)? How are you adding resources to the library?
Per your description your user id has datareader & datawriter permissions. Ideally this is enough to perform the operations once after the tables are being created. You have mentioned that you have to add instance name in order to access files. I haven't faced this trouble before.
Can you please try getting db_owner permission to the user id (for your documaker DB alone). This will enable your user id to create the tables using studio itself while creating workspace. By creating a test library completely via studio you can check how it goes. Hope this will help you in locating the root of the problem.
You can drop the test tables later using SQL client.
Previewing the resources in Library manager does not have to extract to disk (I don't think), therefore this may not be a drive restriction. I'm no DBA, but there are several tables and indexes involved in setting up the library. The resource information you see in the library table in DMStudio is in one table and the contents of the resource are stored in a second - related table. There are also indexes created on those tables and perhaps one of those is missing?
As I said, I'm not a DBA, but I know there are numerous access attributes and you may be missing a key one. Perhaps you can have your DBA determine if the users have the same access to all tables. You might ask that they temporarily give you full access rights to all of the library manager tables to see if you can then access the contents.