I'm using Hitachivantara Pentaho BI community edition v9.1 on a reporting server.
Reporting server stopped working properly because Generated Content folder was bursting of report auto-generated files. There were so many files that UI was unable to load folder content as individual files, so as soon as UI loaded with a minimum functionality after several hours, I could select complete folder and move it to trash.
After that I'm experiencing an error when trying to permanently delete the Generated Content folder from trash folder:
Error subject is:
"You do not have permission to delete this file. Contact your administrator for assitance".
The issue is I already own administrator privileges.
I can't move again problematic folder to its original location and try to delete individual files first, because reporting server stops working as soon as it completes the task due to huge number of files.
Any help is welcome.
Related
For the life of me I cannot find where Pentaho stores the user-created CDE Dashboard files in the file structure? I am using the Community Edition, and I assumed that all the files would be stored in /biserver-ce/pentaho-solutions. When I sign into the Pentaho User Console and select Browse Files, the folders I see do not match what I see in the pentaho-solutions directory. For example, there is a "Steel Wheels" folder in the Browse Files pane, but I cannot find it in the Pentaho directory. Similarly, if I create a folder and a CDE Dashboard within it, I cannot find it in the Pentaho directory. I have done find / -name "*.wcdf" and it doesn't find the CDE Dashboard I created.
I have tried a couple tutorials where I manually create the CDF files, such as index.properties, index.xml, the .xcdf file and .html file, and if I place the files in a folder in the /biserver-ce/pentaho-solutions directory (and of course, stop and start the Pentaho server), I do not see the dashboard show up in the Browse Files pane through the Pentaho User Console.
The files must be somewhere; likewise, if we manually create the files per the tutorials, they must be able to be placed somewhere for the PUC to pick them up. Can anyone please help? Sadly, I have already spent hours on this and not sure I will be able to figure this out without some help.
AFAIK, it depends on Pentaho version. From Pentaho 5 till current Pentaho 7 the Jackrabbit JCR repository is used to sort of 'emulate' a file system, but with possibilities to store the entire system in different storage types. Most of Pentaho server objects, such as CDF dashboards, datasource definitions etc are stored in this repository. In the default pentaho installation JCR uses a database with name 'jackrabbit' in your DBMS to persist its state. But the actual repository location can be defined somewhere in configuration files in pentaho-solutions/system/jackrabbit/ directory.
You cannot directly access the dashboard files outside the pentaho
server. If you want to access these files outside then you need to
download these files, you can download
dashboard.wcdf,dashboard.cda,dashboard.cdfde files from Pentaho your
console. Then again if you want to send your dashboard to your friend
or someone you can upload these files in pentaho user console.
I have a windows form application that requires users to log in to access the information. I have created a local compact database file for the credentials to be stored. I added the database file to my the folder but when I open my application and try to log in it tells me that it cannot find the database file.
Should the file be stored on a different folder, or should I need to install an instance of sql on the user computer.
This is my first deployment so I am not sure how to go about it. I have done some research on the subject, but it does not seem related to my issue. The help section of Intallshield was not clear either.
I am looking for some resources on how to accomplish this.
I figure out the issue, in order to work all files, including the database files need to be dumped under the userprofile folder.
Under VB.Net 2005, I created a Setup Project which produced installation files for a windows application. I placed the mdb file in the User's Application Data Folder and remapped the DataDirectory to Environment.SpecialFolder.ApplicationData at runtime. Unfortunately, sometimes the system just did create the mdb file at the Application Directory. An example was that I installed the program in Windows 7 under a normal user account. I chose inside the installer that the program would be made available to everyone. After installation, the mdb file would be created automatically for the Administrator account but not for the normal user account. For XP, the whole thing worked fine.
I am tempted to write a routine to check and create the mdb file if it is not present, but why does this happens and what other opinions do I have?
If the application is installed for all users instead of once for each user that logs onto the machine, then you will eventually run into a problem where the database isn't available for the signed on user.
In order to resolve this, you would probably be better off checking for the existence of the database on application startup and then either copying a standard version from the application directory to the current user's data directory or creating a new db from scratch in place. I would recommend the first approach.
I have a remote server running SQL Server 9.0.3042, trying to subscribe to a publication on a server running SQL Server 10.0.2531.
These servers are on different domains which basically hate each other and largely refuse to allow their users access to each other.
They do both communicate nicely with a third domain, and it is a user from that domain which I am using as the process owner on both servers.
I have created a shared folder on the publishing server, and I am using it as the Snapshot folder, set via Publication Properties -> Snapshot -> "Put files in the following folder" and have confirmed that the files are being published locally and can be accessed via the shared folder.
The Snapshot Agent on the publishing server runs and appears to complete successfully.
I've then created a Pull subscription on the subscribing server and told it to run with the Agent Process Account of the same user that runs the snapshot agent on the publisher.
I've redirected the snapshot location to "Alternate folder" and set that folder to be the shared folder on the remote server that I set up earlier.
The Pulling server connects correctly to the Publishing server, And then fails because "The process could not read file "\[server].[domain][share][snapshot directory][file].pre" due to OS error 5"
I've logged into the Pull server as the executing account and manually navigated to, and opened, that file. I've done the same on the publishing server.
I'm out of ideas. What am I screwing up?
OS Error 5 is ERROR_ACCESS_DENIED. You're not being allowed to get to the folder. Check to make sure that the user account trying to get to the files has at least read access to the folder containing the files.
The decision has been taken that we're pretty much on the point where we're going to move every user in the company over to a brand new domain, and that this problem isn't worth the time and effort of fixing.
I did find this SO question which relates a similar problem, but I don't intend to investigate this matter any further.
I have an SQL Server database where I have the data and log files stored on an external USB drive. I switch the external drive between my main development machine in my office and my laptop when not in my office. I am trying to use sp_detach_db and sp_attach_db when moving between desktop and laptop machines. I find that this works OK on the desktop - I can detach and reattach the database there no problems. But on the laptop I cannot reattach the database (the database was actually originally created on the laptop and the first detach happened there). When I try to reattach on the laptop I get the following error:
Unable to open the physical file "p:\SQLData\AppManager.mdf". Operating system error 5: "5(error not found)"
I find a lot of references to this error all stating that it is a permissions issue. So I went down this path and made sure that the SQL Server service account has appropriate permissions. I have also created a new database on this same path and been able to succesfully detach and reattach it. So I am confident permissions is not the issue.
Further investigation reveals that I cannot rename, copy or move the data files as Windows thinks they are locked - even when the SQL Server service is stopped. Process Explorer does not show up any process locking the files.
How can I find out what is locking the files and unlock them.
I have verified that the databases do not show up in SSMS - so SQL Server does not still think they exist.
Update 18/09/2008
I have tried all of the suggested answers to date with no success. However trying these suggestions has helped to clarify the situation. I can verify the following:
I can successfully detach and reattach the database only when the external drive is attached to the server that a copy of the database is restored to - effectively the server where the database is "created" - lets call this the "Source Server".
I can move, copy or rename the data and log files, after detaching the database, while the external drive is still attached to the Source Server.
As soon as I move the external drive to another machine the data and log files are "locked", although the 2 tools that I have tried - Process Explorer and Unlocker, both find no locking handles attached to the files.
NB. After detaching the database I tried both stopping the SQL Server service and shutting down the Source Server prior to moving the external drive - still with no success.
So at this stage all that I can do to move data between desktop and laptop is to make a backup of the data onto the external drive, move the external drive, restore the data from the backup. Works OK but takes a bit more time as the database is a reasonable size (1gb). Anyway this is the only choice I have at this stage even though I was trying to avoid having to go down this path.
Crazy as it sounds, did you try manually granting yourself perms on the files via right-click / properties / security? I think SQL Server 2005 will set permissions on a detached file exclusively to the principal that did the detach (maybe your account, maybe the account under which the SQL Server service runs) and no-one else can manipulate the file. To get around this I have had to manually grant myself file permissions on MDF and LDF files before moving or deleting them. See also blog post at onupdatecascade.com
Can you copy the files? I'd be curious to know if you can copy the files to your laptop and then attach them there. I would guess it is some kind of permissions error also, but it sounds like you've done the work to fix this.
Are there any attributes on the file?
Update: If you can't copy the files then something must be locking them. I would check out Unlocker which I haven't tried but sounds like a good starting point. You might also try taking ownership of the files under the file permissions.
When you are in Enterprise Manager or SSMS, can you see the name of the database that you are talking about? There might be a leftover database in a funky state. I'd make sure that you have a backup or a copy of the mdf somewhere safe. If this is the case, maybe try dropping the database and then re-attaching it.
I would try backing up the database on the desktop, and then see if it will restore successfully on the laptop. Doesn't explain your issue but at least you can move forward.
Run sqlservr.exe in debug mode with the /c switch and see what happens starting up. Any locking or permissions issue can be put to bed by making a copy of the file and transfering the copy to the origional.
Also check the associated log file (.ldf) .. If that file is missing or unavaliable you will not be able to mount the database to any sane/consistant state without resorting to emergency bypass mode.
I've had a similar issue. Nothing seemed to resolve it - even tried to reboot the machine completely, restarting SQL services etc. ProcMon and ProcessExplorer were showing nothing so I figured - the "lock" is done by OS.
I resolved it by DELETING the file and restoring it back from the drive mounted under another drive letter.
PS. My database file was not on a USB drive, but on a TrueCrypt-drive (in some you can say it's a "removable drive" as well)
Within SQL Server Configuration Manager, look in SQL Server Services. For all your SQL Server instances, look at which account is selected in the Log On Tab - Log On As:. I've found for instance, changing it to the Local System account resolves the issue you've had. It was the only thing that actually worked for me - and certainly, no shortage of people have had the same problem.
It's a security issue on -file level security - you have detached db with different credential and attaching it with other credential - just browse the article http://www.sqlservermanagementstudio.net/2013/12/troubleshooting-with-attaching-and.html
And try copy pasting it to different location.
I solved similar issue by granting system administrator to all permissions:
right click > properties
security tab
in group or usernames click edit.
click add > advanced
click find now to list all available permissions.
choose administrator and add it to list.
grant it to has full permission.
I had the same issue. Someone had detached the files and left, and we were unable to move it to another drive. But after taking ownership of the file (security-->advanced-->take ownership to your login id), and then adding your login id to the security tab and giving access on the file, was able to move.