use Azure CLI https://learn.microsoft.com/en-us/cli/azure/purview/account?view=azure-cli-latest#az-purview-account-add-root-collection-admin to add root collection admin permisson to others for purview account. Actually ,the use was added after executing command line ,but it needs almost one hour to take effect. this doesn't make sense
I have been using purview for quite sometime but never faced the issue with collection admin permissions reflects in 1+hour. It happens instantly.
If you still having issues, I suggest you to raise a support ticket.
Related
I have an Access 2013 database split across a network that is mainly used via Citrix. I keep getting the error message that the database is in an inconsistent state and I don't know why. I created a query to capture the user name and machine id as a auto-exec macro so I can go back and ask users what happened etc. But what I'd like to know is if it would be possible to know which user first encountered this error? Can I trap the error somehow and know which user "caused" it? I have a feeling that this error happens prior to the auto_exec macro firing but I live in hope.
What I am hoping to be able to do is get with the Citrix team and see if they have a corresponding error or something in their logs.
.. sadly they are all sharing the same front end. It's only being used
for read-only lookup purposes. I wanted each user to have their own
copy but IT disagreed with me.
The only way it could work reliably, is if the accdb file itself is marked as Read-Only, and that would probably leave your application useless.
I've been through this with a client running a huge Citrix setup (40000+ employees) for an application with a priority. IT had for a reason a strict view on security, but though quite cooperative, they were of little help.
However, I got it solved by a VB script. It worked in the first attempt and so well, that I wrote up a description here:
Deploy and update a Microsoft Access application in a Citrix environment
The great thing is, that you probably won't need IT to do anything for you.
From phpMyAdmin, I was exporting the functions/procedures used by the user assigned to a particular database and 3 functions didnt get exported because they were created by the 'superadmin'.
I was able to see these functions within
localhost > database_name -> Structure -> Routines
BUT, I was not able to modify their structure or export them.
The problem was happening because these 3 functions were created by the superuser. When exporting from the superuser account, everything got exported properly.
My question is: as a process, how can I ensure that this doesn't happen again in the future - that someone accidentally creates it as a superadmin (and the site would continue to work fine), but when we try exporting it, the function doesnt get exported (and the new site would stop working).
Restricting access to the superuser account would be the first step I would take. By restricting superuser access you guarantee that no one makes that mistake again. Is there a reason someone would need to be in the database working as a superuser?
The database that I am working on (in MS-Access XP) seems to have become corrupted somehow. It no longer supports any events - clicks, change, update events, nothing seems to work. This is the error that I get:
The expression On Change you entered as the event property setting produced the following error: Object or class does not support the set of events.
What can I do to make events start working again? I have tried Tools->Database Utilities->Compact and Repair Database..., but it didn't help at all. Also, it hasn't been like this the whole time - events were originally working, but now nothing works, not even the auto-generated command buttons.
Compact and repair generally won't solve problems that happens in objects other than tables and indexes. Importing usually fixes those but maybe try a decompile and then an import. Decompile or how to reduce Microsoft Access MDB/MDE size and decrease start-up times
I encountered the same problem once and documented my trouble shooting steps here. The expression On Click you entered ...
Also see Corrupt Objects within a Corrupt Microsoft Access MDB
Long discussion summarized.
One page that might have a solution that might help is Errors using multiple versions of Access under Vista/Windows 7 This is basically a permissions problem into the registry.
Another suggestion is to to repair the Office 2003 installation in control panel. A2003 then reverts to using Version 11 of the library, but only until A2007 is used again, then the problem reappears.
The original poster stated "Okay, after a few restarts, it seems that removing the 2007 runtime did fix the problem for me. "
Tony alluded to this in his long string of comments, but this sounds exactly like the dueling Access registration problem. I hadn't used A2007 until recently (I had the runtime installed to test if a database developed in A2003 could be deployed under it -- it could -- but hadn't used it since that testing was completely), and when I run A2007 after I've been using A2003, it has to reconfigure itself. The other day, something went wrong during the A2003 reconfiguration (after having last run A2007) and I got errors similar to yours. Running A2007 (to re-register everything as A2007) and then running A2003 (to re-register everything as A2003) fixed the problem.
The key is that when the re-registration fails, Access doesn't necessarily know it the next time it runs, so you end up running in an environment that is partly registered for A2003 and partly for A2007. The way to restore it is to run the other version of Access. That is, if A2003 is launching without the reconfiguration notice, then close it down and run A2007 so it reconfigures itself and re-registers itself as the real Access. Then when you run A2003 next, it will re-register itself as the authoritative version of Access and your A2003 app should have all of its references in proper shape.
Yes, this is very annoying.
And time-consuming.
I don't know why MS seems to think this is something that doesn't need to be fixed. While I know they don't give a rat's ass about developers who need to run A2003 and A2007 side by side, there are plenty of end users who might have an A2007 runtime app installed but also have A2003 installed as part of their base Office installation.
This has been going on forever, so I doubt it will ever be fixed.
I have encountered the same problems many times in Access 2013. From a page on MS web site, I found the answer which solved my problem. I am sharing it here.
I copied the code safely somewhere else outside Access, in the Notepad++.
Then I deleted entire vent Procedure, with its code, which was not firing.
Created fresh Event procedure, and restored the code from Notepad++ to the newly created Event Procedure.
The event earlier not firing started without any glitch. The issue got solved.
I don't know why the problem appears. This problem has come up many times and every time it is resolved with the same solution.
Try it.
Try to decompile and recompile the database.
If that does not work, I usually create a new database and import everything from this one to the new one. If something is corrupted, I will encounter issues at that time and be able to fix it.
Can you see the code in your code modules? If so, cut and paste it somewhere safe. Then flip the HasModule setting for each form to false, repair the database, and restore the code to newly created code modules.
You decompile the database by adding the flag /decompile to the start-up options i.e.
msaccess.exe “C:\my_folder\mydb.mdb” /decompile
I find that solves most of my problems. If not then another one is to re-secure the database by running the security wizard. This basically makes a new db and imports all the objects for you
I had a similar problem. When it started I created a new version of the code by copying the database. This did not help. However, deleting the form from the new database and importing it from the original solved the issue. I did not receive any warnings of corrupted code or other. It simply just worked without any changes to the VBA etc. Bit weird all in all
I compacted the database (Access 2010) into a new one. No joy. Deleted the form that was not working and imported it from the old database. No joy. Recompiled. JOY! Not sure why it quit and why it now works. I suspect a problem with a large amount of text in a linked text box on the form.
We have an access database on a file share that has permissions for everyone in the department to access. The problem i am having is that when multiple users try accessing the database at the same time they are unable to do this. One user can open the database fine but when another user tries to simultaneously, they double click the file icon, get an hour glass for a split second and nothing happens after. We are using Server 2003 as our domain controller. All permissions have been verified on both a domain level and in the access database under tools-options-advanced and setting relevent permissions to shared and no locks. Do you know what could be causing this issue with a "dead link" when user try to open the file simulateneously?
Any help is greatly appreciated.
Thanks.
Ignore the naysayers - Access is perfectly fine for a small number of users. Either you have the default Access settings to open dbs exclusive which will lock out other users or there is some weird network problem.
EDIT
- noticed you already have default shared access
- is record-level locking on?
- also try giving user full control of the shared network folder (Access needs read/write/create/delete to be able to create and delete the ldb file)
This issue occasionally happens to Access databases for almost no apparent reason. Of the suggested responses by Microsoft, you are already doing the second (opening from within Access) but I believe the first provides somewhat of the answer you are looking for.
In the target of the shortcut, include
the path of MSAccess.exe
According to Microsoft Help and Support
When you say share permissions, do the users have full permissions? Full permissions are needed because the share file (.ldb) must be created and deleted.
I am just recently experiencing the same issues, only one person can open the database. We only have 3 people accessing the same database through shorcuts on our desktop.
Now according to Microsoft we need to include the database path in our shortcut, I will tried that. They acknowledge this problem.
MS Access is not worth the trouble in a multi-user setup.
Your time is better spent converting the database over to a server-based RDBMS such as SQL server while you still have hair.
Believe me, you will have to do it sooner or later anyway! Sorry for the bad news.
I want to build a web based front-end to manage/administer my Linux box. E.g. I want to be able to add users, manage the file system and all those sorts of things. Think of it as a cPanel clone but more for system admin rather that web admin.
I was thinking about creating a service that runs on my box and that performs all the system levels tasks. This way I can have a clear separation between my web based front-end and the actual logic. The server pages can than make calls to my specialized server or queue tasks that way. However, I'm not sure if this would be the best way to go about this.
I guess another important question would be, how I would deal with security when building something like this?
PS: This just as a pet project and learning experience so I'm not interested in existing solutions that do a similar thing.
Have the specialized service daemon running as a distinct user -- let's call it 'managerd'. Set up your /etc/sudoers file so that 'managerd' can execute the various commands you want it to be able to run, as root, without a password.
Have the web server drop "trigger" files containing the commands to run in a directory that is mode '770' with a group that only the web server user and 'managerd' are members of. Make sure that 'managerd' verifies that the files have the correct ownership before executing the command.
Make sure that the web interface side is locked down -- run it over HTTPS only, require authentication, and if all possible, put in IP-specific ACLs, so that you can only access it from known locations, in advance.
Your solution seems like a very sensible solution to the 'root' issue.
Couple of suggestions:
Binding the 'specialised service' to localhost as well would help to guarantee that requests can't be made externally.
Checking request call functions that perform the actions and not directly give the service full unrestricted access. So calling a function "addToGroup(user,group)" instead of a generic "performAction(command)".