We use Azure SQL Database, and therefore had to jump through some hoops to get cross-database queries set up. We achieved this following this great article: https://techcommunity.microsoft.com/t5/azure-database-support-blog/cross-database-query-in-azure-sql-database/ba-p/369126 Things are working great for most of our databases.
The problem comes in for one of our databases which is read-only. The reason it's read-only is b/c it is being synced from another Azure SQL Server to derive its content. This is being achieved via the Geo-Replication function in Azure SQL Database. When attempting to run the query GRANT SELECT ON [RemoteTable] TO RemoteLogger as seen in the linked article, I of course get the error "Failed to update because the database is read-only."
I have been trying to come up with a workaround for this. It appears user permissions are one of the things that do NOT sync as part of the geo-replication, as I've created this user and granted the SELECT permission on the origin database, but it doesn't carry over.
Has anyone run into this or something similar and found a workaround/solution? Is it safe/feasible to temporarily set the database to read/write, update the permission, then put it back to read-only? I don't know if this is even possible - I was told by one colleague that they think it will throw an error along the lines of "this database can't be set to read/write b/c it's syncing from another database..."
I figured out a work-around: Create a remote connection to the database on the ORIGIN server. So simple, yet it escaped me until now. Everything working great now.
Related
I am a .Net / SQL Server programmer. I am trying to make an Access database created by someone else to work. It looks like is uses a procedure similar to Save password for ODBC connection to SQL Server from MS Access 2007 but I am using Access 2003 so I suspect something else needs to be done. I don't really know what I am doing with Access but I am stuck with it.
I do have an ODBC connection and it looks like the linked tables use it. The database has an AutoExec which populates some local tables from the linked tables that the reports use. It also calls a qryConnect with a dsn-less connection like the linked article and this seems to work. I have got it to stop asking for a user and password on start up. I can also open most reports without problems, 2 do not work. A form loads on Startup with buttons that basically show reports. This is where it gets odd.
The reports fail from the ODBC driver with the windows credentials. Then a logon box shows up with the correct user (a user with read only privileges) but the trusted connection box is checked. I do not have the trusted box checked in the DSN. Not do I have Trusted_Connection=Yes in the DSN-less connection in qryConnect.
This is the code in the form
stDocName = "rptNegativeLotQtys"
DoCmd.OpenReport stDocName, acPreview
I don't know how I buggered it up so much and before I try again copying everything to a new mdb and trying again I am hoping to get some guidance.
On a side note I can open everything fine on my machine. I am an administrator as far as Windows is concerned but not SQL Server.
EDIT:
I created a new DSN just for these reports. Then I deleted all linked tables and re-linked then using the new DSN. I looked at the linked tables in MsysObjects and the new DSN is listed there. Yet Access still prompts for the password. It appears that it is not caching the password.
Actually, you do NOT need to add nor store the UID/Pass in the connection strings used. However, what you MUST ensure is that all connection strings are the SAME. If they are different, then the cached UID/password will not work.
Also, make sure you do NOT connect nor open a table AFTER having connected using Windows Auth – the reason being then when you add the table links (especially via code), then the cached setup of using windows auth will occur, and thus prompts will occur when the links suggest to do otherwise. In other words linking and attempted to use SQL logons will NOT work if you already opened any table link via windows auth (so exit the database and do NOT open any table that could/can use windows auth).
So I would delete the links, and re-create them – but again, ensure that you never connected as a windows auth user to SQL server.
So the "cache" that access has is a GREAT friend/feature to eliminate the need to include UID/pass in the connection string - but the SAME feature will bite you VERY bad if you at any time connecte to the database in question via windows auth.
How to “cache” the user logon and ID is explained here:
Power Tip: Improve the security of database connections
http://blogs.office.com/b/microsoft-access/archive/2011/04/08/power-tip-improve-the-security-of-database-connections.aspx
So you “can” include the UID/LOGON in the linked tables, but above shows that a ONE time logon can also be used. So be VERY careful when setting up table links – due to the above “cache” of the user and HOW they logged into the database – code that ATTEMPTS to create table links based SQL logons will actually wind up using windows auth if you already connected as such (so exit the database if you going to re-link using SQL logons).
Keep in mind, Access does NOT use the DSN AFTER you linked the table. The information from the DSN is a ONE TIME copy to the connection string. You can verify this by going into my documents and deleting the DSN you used. Assuming the linked table was working correctly, you find that they CONTINUE to work EVEN if you delete the DSN. In effect this means that linked tables are DSN less except for when you create the linked table. This allows you to easy copy the application to different computers without having to copy the DSN.
As to ensure that all the linked tables use the same connection string, it is a simple matter to delete them all, and re-link.
You can also hit ctrl-g to bring up the debug window, and look at the connection string this way:
? currentdb.TableDefs("linked table name").Connect
the result in the debug window for a windows auth connection string will look like this:
ODBC;Description=test DSN;DRIVER=SQL Server;
SERVER=albertkallal-pc\SQLEXPRESS;
Trusted_Connection=Yes;
APP=Microsoft Office 2010;DATABASE=AxisMIS
Note how in above we see "trusted connection" (that means windows auth).
If I linked the table using SQL logon (and REMEMBER to check save password), then you see this:
ODBC;Description=TEST3;DRIVER=SQL Server;
SERVER=ALBERTKALLAL-PC\SQLEXPRESS;
UID=MySQLogon;PWD=MyPassword;
APP=Microsoft Office 2010;DATABASE=AxisMIS
Just remember during the table link process to "check" the save password.
eg this:
I'm using SQL Server 2008 (without application server or anything).
Numbers of users can be up to 1000. Windows Authentication is used.
The question is:
How to handle modes, so
some users will be allowed to work
in read-only mode
some users won't
have access to db for some time
My versions:
Using a table with a mode id for
every group of users, that will work
the same way. On Form Load
application will query that table
for mode id.
Using trigger on the tables, that
must work according to that mode.
The trigger will query mode value
and doesn't work if access is closed
or it's in read-only mode
I know these are not the best solutions, that's why I'm asking for your advice.
There's one more point.
If the mode is changed to "access-is-closed" for a group of users, that group must not be able to query to DB starting that moment.
With first solution I wrote it won't work, because user can be in application at that moment and no form load event will work. How can I do this?
Is there any optimal solution?
Thank you. Any help would be appreciated.
It depends somewhat on how you Access app interacts with the server, but for number 1 why not just use the built in Role/User permissions system in SQL Server?
For number 2, as your using Windows Authentication you can restrict logon hours in active directory on a per-account/OU basis this should prevent them from logging on to SQL server.
You could also do it via Logon Triggers which would not also prevent access to other domain resources.
I have a console app that's geared to be automatically ran as a Scheduled Task. I use LINQ to SQL to pull some data out of the database, format it into a CSV and email it to a client. All of a sudden I am getting the error "SELECT permission denied for table", but the account I'm using to connect to the database (specified in my app.config file) has the "sysadmin" server role (bad programmer, I know; I'll get around to changing it to a better account later but I want to make sure it works first).
I can connect directly to the SQL database using that very same account and query the table in question without a problem, it only seems to be when using the LINQ code. Any idea what would be causing this?
Same server and database?
The error should actually say something like "does not exist or do not have permission". Now, if you're sysadmin then permission is irrelevant so table must not exist where you think it is
Ideas:
Wrong server
Client SQL alias pointing to wrong server
Wrong DB context
Wrong schema (eg SELECT * FROM bob.myTable should be SELECT * FROM fred.Mytable)
Try SELECT ##SERVERNAME, DB_NAME() (or Linq equivalent) to see where you are as a first step...
I have two databases, production and stage. I am getting the error message in the title of this post when I click "Database Diagrams" for production, but on stage I don't get an error.
I've researched this message, and I've found posts such as this:
Link
They pretty much say to change the owner of my database to sa. I'm not convinced this is the issue, though, because both production and stage databases have the same owner (not sa), but I only get this error for production.
Does anyone else know how else to resolve this error message?
both production and stage databases
have the same owner (not sa), but I
only get this error for production.
That usually is the very source of the problem: a database created on one machine is restored on a different machine where the SID of the original creator is no longer valid. Change the owner to a valid one:
ALTER AUTHORIZATION ON DATABASE::[<dbname>] TO sa;
I received this error. In my case, I had existing Diagrams but could not view them on account of this error. I remembered that I had changed the name of the server a week or so ago. After renaming the computer, SQL Server (2012) apparently correctly began using the correct underlying local user object in the Logins section of Security. So, from appearances, the database had a valid owner. But the name of the security account wasn't changed - the username of the owner was correctly localputer\localuser but the SQL account name was local-puter\localuser (the original name of the server). I renamed the account name to localputer\localuser and everything went back to normal. I did not need to issue an ALTER AUTH ON DB.
Following on from my last question:
I've written some code to upgrade a SQL Server database. Before I upgrade the database, I plan to limit access to the database with the following statement:
ALTER DATABASE Test SET SINGLE_USER WITH ROLLBACK IMMEDIATE
Before running this code, I'll give the user an opportunity to opt out. At the time of prompting the user, I thought it would be nice to show the list of active connections (continuously polled at a set interval); providing the user with a tool to identify applications/users they would like to boot off the server before proceeding.
In SQL 2000, you can use the sys.sysprocesses table to see all connections that apply to a database. This includes connections that have no active request (like when you open a Query Analyser window and select a database).
However, using:
sys.dm_exec_connections
sys.dm_exec_sessions; and
sys.dm_exec_requests
I couldn't figure out a way to achieve the same outcome. It appears that these views only tie connections to a database through a request. Is there a way to mimic the behaviour of sys.sysprocesses? I'd prefer not to use this table for SQL Server 2005/2008 databases.
Er... I recommended these for your other question.
Sorry, but, I've found out that you still have to use sysprocesses
It's logged as a bug in Microsoft Connect 144515 to be fixed, I found it here
Personally, I still use sysprocesses because I'm comfortable with it, however lazy and luddite that may be...