Background
I maintain an application which spans multiple databases on a Microsoft SQL Server, let's call them PROD and ARCHIVE. For audit purposes, when a user accesses the databases through the application, their credentials are used on the database.
In some installations of this application, ARCHIVE doesn't exist, and code is in place to handle it not being present in sys.databases. But when ARCHIVE exists, everyone has access to both PROD and ARCHIVE.
Problem
We'd like to be able to fragment the application such that all users retain access to PROD, but some users aren't able to access ARCHIVE. In those cases I'd like to leverage the branching we have to check both whether ARCHIVE exists and whether the current login has any access to it.
Not that bad, except that I have to be able to run the query that finds it out with only access to PROD, and most of what I can find online is giving me queries to run against ARCHIVE.sys.database_permissions.
Is there a query I can run to verify that I cannot access ARCHIVE when I only have access to PROD?
HAS_DBACCESS
A little more searching got me to this:
HAS_DBACCESS returns 1 if the user has access to the database, 0 if the user has no access to the database, and NULL if the database name is not valid.
(via MSDN)
So what I needed in this case ended up being pretty simple:
select cast (ISNULL(HAS_DBACCESS('ARCHIVE'), 0) as bit);
which runs just fine on PROD. I'm not 100% sure on this because it'll also return false if the database has been taken offline, which is something I might actually want user-end visibility on, but that's something later development will need to deal with.
Related
I have 2 DB2 databases (testing and production). In order to move tables between them, some users have a (probably coded by an admin) function called ftpfile from inside the emulator. I do not have access to the said emulator, my account has *INITIAL_MENU_NAME = 'SIGNOFF' but I can connect from third party tools like DBeaver. Is there a way to move tables between environments?
It would seem very unlikely for you to have the authority to "move tables".
You might be able to copy the data.
The easiest way would be something like so, while connected to the destination system.
delete from library.table
with nc;
insert into library.table
select * from system2.library.table
with nc;
But being able to do that requires that the systems and your user profile be configured to allow it.
Really the right answer here is for you to contact your admin/security team and get the access required to do your job.
I have a shared accde file on a network drive. Occasionally we will have an inconsistent state problem. The error message appears below. It seems to be associated with network connection interruptions for even one user. We have an example when a user unplugged the Ethernet and switched automatically to wireless and other examples where users have left the database open overnight, perhaps when a machine hibernates.
Once this happens the one user cannot work and no one can open the accde file. Other users who have the database open can continue to work.
After the problem occurs it remains until everyone closes the database. At that time it completes whatever recovery it requires and all users can get back in.
This was disruptive when we had six users in one room. Now we have 17 in two cities and a few work-from-home users. It's becoming intolerable.
The obvious answer is to move away from Access. We're working on it but it's a long way off. In the mean time I would appreciate any advice.
Is there a way to prevent the problem entirely?
Is there a VBA way to detect the problem in the instances that are not showing the error message?
Is there something I'm not thinking of?
What would you do?
Error message:
Microsoft Access has detected that this database is in an inconsistent state, and will attempt to recover the database. During this process, a backup copy of the database will be made and all recovered objects will be placed in a new database. Access with then open the new database. The names of objects that were not successfully recovered will be logged in the "Recovery Error" table.
The solution that Microsoft gives is Splitting the database, which just means to put the data elements on a shared server, and everyone has their own copy of the front end.
This might cause problems if that front end needs to be updated (e.g. additional forms). Details here:
http://answers.microsoft.com/en-us/office/forum/office_2007-access/microsoft-office-has-detected-that-this-database/3fb41c70-f7ba-41dd-a847-e62203071466?auth=1
Check the row count in the tables, the tables most likely have large amounts of data creating latency on the read and write queries, causing the locking.
Archive older data and keep the database small and neat, perhaps create referenced databases for archived information
I gather that your MS Access database is getting corrupt when up put it on a shared drive. A Microsoft Access database may get corrupt when in a multi- user environment. Here are the workaround that you can use in order to fix it.
Step 1: Run Command Prompt as Administrator
Click on the Windows icon and type Command Prompt. Then right-click on the Command Prompt and choose Run as administrator option.
Step 2: Execute Compact and Repair Database Command
In the command prompt window, type the following command and then press ‘Enter’.
msaccess <database file name> /compact
In the command, replace <database filename> with database path. For instance,
msaccess "C:\Program Files\Reports.mdb" /compact
This will start the process to compact and repair the faulty Access database file.
Otherwise, You can check out this thread for an alternative solution : https://dba.stackexchange.com/questions/71906/ms-access-mdb-ldb-database-corrupted/171275#171275
In my SSDT Project, why could I be getting this error?
"the select permission was denied on the object __refactorlog?"
There is a refactorlog item in the Project.
I select to generate a publish script from inside VS.
Edit: the target is a production server, so I don't have permissions to create tables or select data there, I just have to create the deployment script, and there is no table __refactorlog anyway..
You need greater permissions than you currently have on that server in order to generate a publish script. I verified that there is a call "SELECT OBJECT_ID(N'dbo.__RefactorLog')" in the code handling refactor operations that checks if the table exists. It's likely that the code is failing at that point as you don't have the permissions to even ask to select the object. You can check this yourself by running that query against the database and seeing if you get an error.
Suggestions for determining the permissions you need:
Try right-clicking on the database and choosing "Create New Project". If you can't extract the database definition to a project then it's a clear sign that you don't have View Definition privileges on the database
If that's not the case, then the issue is that you need read permissions on the __refactorlog table and don't have it. The solution would be to get access to that table, or else you'd have to verify none of the refactorings are needed and delete the refactorlog from the project (not recommended as generally you want to preserver refactorings to avoid possible data loss and other issues).
Here is how I handle this, even though it is a poor substitute and is not useful for automating database publishing. I write the publish script, then do a global search and replace, changing "dbo" to a schema that I can access. That works for me, because I have removed all the options that attempt to script objects I do not control, and the dbo schema is completely out of my hands, same as you.
I am not proud of this, and I wish that I had the option of controlling where that table could reside, but at least the Visual Studio features of refactoring are completely supported.
I am having trouble sorting through all the information / various options in regards to Access 2007 used in a multi-user environment. Here is a brief description of my current situation. At work there is the "Business LAN" which I can log on and use to monitor two other servers via remote desktop. The business LAN is strictly controlled by our IT department and no one is permitted to install any software or drivers without their consent. I do have administrative privileges on both servers though.
The two servers that I log on to using RD are used for essentially the same task, which is to monitor and control the heat to different process lines. Each server runs a different program to accomplish this task but both programs use SQL Server as a back end.
I created two access databases (one on each server because they are currently behind seperate firewalls) in order to query information from the backend SQL side of these programs and combine it with relative information I have compiled in tables in order to add more detail to the data the programs are collecting. My program is still in the debug stage but ultimately this information can then be accessed by field techs / maintenance in order to make their job easier. Maintenance staff can also add even more information based on the status of repairs etc....Last, I have created reports which can be run by Managers / Engineers who are looking for an overall status of their area.
Both access db's are split so that the back ends are seperate from the forms, queries, etc... I use an ODBC data source to import a link to SQL. I am using vba for user authentication, user logging record updates, and user / group access control. Everything works the way I intended except the fact I everyone who logs on the server will be trying to run the same copy of the front end. For example, I had a co-worker log on to the server via RD to test the program and I logged on from my desk. After logging in I could see the forms he had open. Access was already running. Without being able to install access locally (or even runtime, due to IT restrictions) on to each individuals workstation, I'm not sure what approach to take to resolve this.
Additional info, Server 1
One of the servers is considered to be the "master server" in which a number of client stations "slave servers" all communicate with. The only way to access folders on themaster server is log on to the client station and run RD.
Server 2
This server is considered to be the "historian". It communicates with a terminal server in which users log on using RD and run applications which use SQL backend which resides on the historian. I have been able to set up shares so that certain folders are visible on the historian from the terminal server.
Can anyone tell me what my best option is?
Thanks in advance.
CTN
It's really crazy the way some IT departments do everything possible to make it hard to do your job well.
You allude to users logging on via Terminal Server. If so, perhaps you can store the front ends in the user profiles of their Terminal Server logons? This assumes they're not just using the two default admininstrative Terminal Server logons, of course.
The other thing that's not clear to me is why you need a back end at all in Access/Jet/ACE -- why not just link via ODBC to the SQL Server and use that data directly? The only reason to have an independent Jet/ACE file with data tables in it in that scenario is if there is data you're storing for your Access application that is not stored in the SQL Server. You might also have temp tables (e.g., for staging complicated reports, etc.), but those should be in a temp database on a per-user basis, not in a shared back end.
Here is a suggestion how to implement what David Fenton wrote: write a simple batch script which copies your frontend from the installation path to %TEMP% (the temporary folder of the current user session) and runs the frontend from there. Something along the lines of
rem make sure current directory is where the script is
cd /d %~d0%~p0
rem assume frontend.mdb is in the same folder as the script
copy /y frontend.mdb %temp%
start %temp%\frontend.mdb
Tell your users not to run the frontend directly, only via the batch script, then everyone should get his own copy of the frontend. Or, give your frontend a different suffix in the installation path and rename it to "frontend.mdb" when copying to %temp%.
For SQL Server 2008 Developer Edition on Vista 64 bit:
I tried copying a database using a Vista admin account using the attach/detach method and it failed due to a file permission error so I gave the user that sql services are running as write and modify to the directory. The copy didn't work. I then gave it full control. The copy worked.
Does that make sense?
If I revoke full control from the user, will that cause problems?
The weird thing is that in an existing working database with files in a different directory, there are no special permissions on the directory and files for the database, so why does a copy require full control?
When you detach a DB, the MDF/LDF files may be set with more restricted perms than you expect, like exclusive to the principal that did the detach - maybe the SQL Server service account or the domain account of the user that performed the detach. I have in the past had to manually add back permissions on the files' Properties > Security tab for other users, or else the files act as if they are locked. See also http://www.onupdatecascade.com/2009/07/sql-server-locks-mdf-and-ldf-files-upon.html
also: http://msdn.microsoft.com/en-us/library/ms189128.aspx
( thanks GrumpyOldDBA )
If the server and/or data you are working on does not require those restrictive permissions to be set, you can set a startup flag in SQL Server that will override this function. I understand what Microsoft is going for with this - they assume if you detach a DB they don't want just anyone to walk away with the file; however, I think keeping a good hacker from doing that is easier said than done, and encrypting the DB is the best method for safeguarding data.
Anyway, there is a "Trace Flag 1802" which is oddly named, since it's nothing to do with tracing. You'll want to add it to your SQL startup in SQL Configuration Manager if you want to keep this behavior.
https://support.microsoft.com/en-us/kb/922804
I myself had the same issue and found the answer in StackExchange:
https://dba.stackexchange.com/a/77683/11001