I installed sql server 2005 Express in a virtual clean Windows xp machine.
On the database engine I created two instances, each one of these I have configured mixed authentication and the first user 'sa' password is 'password1' and the second 'password2'.
Then in the first instance, I have created a new database with a common table and a few details. Followed by this stopped the first instance I try to attach the database in the second instance. As it was to be expected, this caused an error and the process was aborted.
Then what I did was to change the password for the 'sa' user and I put the same one that was in the one instance ('passowrd1'). Now try to attach the database, the process is run correctly and the database created in the first instance was properly attached in the second instance.
Until here nothing weird, my surprise was given to make the next step.
In the second instance, I have again changed the password to the user 'sa' and this time put it as it was originally ('password2') and the attached database is kept running.
This is the first thing that I don't understand why it occurs in this way. And as last test, I stopped the second instance and start the first, and to my surprise the database also kept running.
Can someone tell me why this behavior is given as well?
My fear is to create a database with a password 'X' and then for some reason someone discover the password and then changing it, if someone attached database in another instance, can use the old password to open it. The same behavior is happening at others editions of sql server?
Are there any security layer extra that recommend me to apply?
The SA password should have no effect on any user-created databases. It only would affect system databases (Master, Model, MSDB, TempDb). Unless, of course, you encrypted your database files or if you are doing a password-secured backup/restore (which, you are not).
When you were unable to attach the first time, I would suspect that the first SQL instance had not finished shutting down yet. It was merely a coincidence that you took a few minutes to change passwords and then were able to attach the original DB file.
If you want to secure your databases, so they are not stolen and attached to another database, I would recommend doing this at the Server OS level. Prevent people from getting to the file in the first place.
Related
I have been experiencing random connection/handshake problems w/ a hyper server VM running SQL and SSRS
So the network guys suggested building a new VM and trying it there. (Have you tried rebooting? )
I asked that they rename the old server (--> SQLBKUP) and name the new server to the current name (--> SQL) so all my connection strings will continue to work.
Regardless the wisdom of that approach, that is all now done.
All of our applications work. (and the weird handshake issue is gone,joy)
I have reinstalled SSRS and I thought I was home free.
We backed up and restored the ReportServer and ReportServerTemp databases to the new server.
If i try to point to these databases , I keep getting this error
The report server installation is not initialized. (rsReportServerNotActivated) Get Online Help
Any all information I can find about this for 2012 says that the initialization happens automatically when you configure a database.
I tried creating a new database, and presto, everything works fine.
I reconfigured SSRS to point at the old database and I again get the rsReportServerNotActivated error.
I also 'powered down' SQLBKUP in case it was causing some confusion, I cant imagine what that might be, but why not... This did NOT correct the problem.
Any ideas on why the databases that were working on 1 server wont work on the new one?
Searching the interweb for this issue I find two results for 2012 SSRS (many hits for 2005 issues/resolutions )
this article details how the RSExec role should be configured, I have verified that is all correct.
https://msdn.microsoft.com/en-us/library/cc281308.aspx
this article details the mechanics of various ways to move a database. The back up and restore operations went off w/o a hitch.
https://msdn.microsoft.com/en-us/library/ms156421.aspx
neither article mentions cleaning up any server names, ip addresses, etc. that might be in a config table. Inspecting the tables in SSMS, I dont see any tables that look like they might need such attention.
I can always recreate the environment, I am aout to that point, at least I will know what I have in front of me. If anyone has any suggestions, i would appreciate it, Im sure I will be up for a while... :-)
tyia
greg
You are getting that error because you haven't moved the old encryption keys to the new server. SSRS uses encryption to secure credentials and connection information. You'll need to get the encryption keys from the old server and restore them to the new one OR if you don't have the keys anymore you can create new ones but you'll need to setup your connection information again.
First backup your old encryption keys:
Start the Reporting Services Configuration Manager, and
then connect to the report server instance you want to configure.
Click Encryption Keys, and then click Back Up.
Type a strong password.
Specify a file to contain the stored key. Reporting Services appends a
.snk file extension to the file. Consider storing the file on a disk
separate from the report server.
Click OK.
Then restore the keys to the new server:
Start the Reporting Services Configuration Manager, and then connect to the report server instance you want to configure.
On the Encryption Keys page, click Restore.
Select the .snk file that contains the back up copy.
Type the password that unlocks the file.
Click OK.
You can also use the rskeymgmt utility, see the MSDN article: Back Up and Restore Reporting Services Encryption Keys.
If you don't have access to the older server you'll need to delete and recreate the encryption keys. Once you delete the keys the server will automatically re-initialize itself and you'll need to re-enter all of the lost encrypted information.
The following things will occur when you delete the encryption keys:
Connection strings in shared data sources are deleted. Users who run reports get the error "The ConnectionString property has not
been initialized." Stored credentials are deleted. Reports and
shared data sources are reconfigured to use prompted credentials.
Reports that are based on models (and require shared data sources configured with stored or no credentials) will not run.
Subscriptions are deactivated.
Steps to delete the keys:
Start the Reporting Services Configuration tool, and then connect to
the report server instance you want to configure.
Click Encryption Keys, and then click Delete. Click OK.
Restart the Report Server Windows service. For a scale-out
deployment, do this on all report server instances.
This is from MSDN - Delete and Re-create Encryption Keys. The article has a lot more useful information.
For more information also read Configure and Manage Encryption Keys
I have been using MS Access databases via DAO for many years, but feel that I ought to embrace newer techniques.
My main application runs on end user PCs (no server) and uses a shared database that is created and updated on-the-fly. When the application is first run it detects the absence of a database and creates a new empty one.
Any local user running the application is allowed to add or update records in this shared database. We have a couple of other shared databases, that contain templates, regional information, etc., but these are not updated directly by the application.
Updates of the application are released from time to time and each new update checks the main database version and if necessary executes code to bring the database up to the latest specification. This may involve the creation or deletion of tables and/or columns. New copies of the template databases are also included as part of the update.
Our users are not required to be computer-literate and should not need to run any sort of database management software beyond those facilities provided by the application.
It all works very nicely with DAO/Access, but I'm struggling to find how to do it with SQL Express. The databases seem to be squirrelled away in locations that are user-specific and database creation and update seems at best awkward to do by program code alone.
I came across some references "Xcopy deployment" that looks like it could be promising, but there seem to be references to "user instances" that sound suspiciously like something that's not shared. I'd appreciate advice from anyone who has done it.
It sounds to me like you haven't fully absorbed the fundamental difference between the Access Database Engine (ACE/Jet) and SQL Server:
When your users launch your Access application it connects to the Access Database Engine that has been installed on their machine. Their copy of ACE/Jet opens the shared database file (.accdb or .mdb) in the network folder. The various instances of ACE/Jet work together to manage concurrent updates, record locking, and so on. This is sometimes called a "peer-to-peer" or "shared-file" database architecture.
With an application that uses a SQL Server back-end, the copies of your application on each user's machine connect over the network to the same instance of SQL Server (that's why it's called "SQL Server"), and that instance of SQL Server manipulates the database (which is stored on its local hard drive) on behalf of all of the clients. This is called "client-server" or "server-based" database architecture.
Note that for a multi-user database you do not install SQL Server on the client machines, you only install the SQL Server Client components (OleDb and ODBC drivers). SQL Server itself is only installed in one place: the machine that will act as the SQL... Server.
re: "database creation and update seems at best awkward to do by program code alone" -- Not at all, it's just "different". Once again, you pass all of your commands to the SQL Server and it takes care of creating the actual database files. For example, once you've connected to the SQL Server if you tell it to
CREATE DATABASE NewDatabase
it will create the database files (NewDatabase.mdf and NewDatabase_log.LDF) in whatever local folder it uses to store such things, which is usually something like
C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLEXPRESS\MSSQL\DATA
on the server machine.
Note that your application never accesses those files directly. In fact it almost certainly cannot do so, and indeed your application does not even care where those files reside or what they are called. Your app simply talks to the SQL Server (e.g. ServerName\SQLEXPRESS) and the server takes care of the details.
Just to update on my progress. Inspired by suggestions here and this article on code project:
http://www.codeproject.com/Articles/63147/Handling-database-connections-more-easily,
I've created a wrapper for the ADO.NET methods that looks quite similar to the DAO stuff that I am familiar with.
I have a class that I can use just like a DAO Database. It wraps ADO methods like ExecuteReader, ExecuteNonQuery, etc. with overloads that can accept a SQL parameter. This allows me to directly replace DAO Recordsets with readers, OpenRecordset with ExecuteReader and Execute with ExecuteNonQuery.
Each method obtains and releases the connection from its parent class instance. These in turn open or close the underlying connection as required depending on the transaction state, if any. So a connection is held open for method calls that are part of a transaction, but closed immediately for a single call.
This has greatly simplified the migration of my program since much of the donkey work can be done by a simple "find and replace". The remaining issues are then relatively easy to find and sort out.
Thanks, once again to Gord and Maxwell for your advice.
This answer is too long to right down... but go to Microsoft page, there they explain how to make it: http://office.microsoft.com/en-us/access-help/move-access-data-to-a-sql-server-database-by-using-the-upsizing-wizard-HA010275537.aspx
I hope this help you!!
I have been asked to maintain a site created in ASP classic that uses a SQL Server database.
I was given the database in the form of a backup. I restored the database on my local computer and created a DSN connection to it. However when I attempt to load my site, the stored procedures the site relies on give an error that execute permission was denied.
The stored procedures in question have a user named UserSecure showing as the only person with EXECUTE permission, I have tried creating a user by that name but that does not work, even though I can manually login to SQL Server Management Studio using UserSecure trying to connect from the web page using those credentials gives a login failed error.
If I run sp_helplogins my Windows credentials are shown as being owner of the database, and I can in fact execute from within SSMS but not from an ADO connection.
On another note the connection in the webpage was coded like this, I am not familiar with the application part of the connection. Perhaps this is part of the problem? I have tried connecting with a DSN and DSN-less connection and can connect but not do anything with the database?
You should make sure the database server login is mapped to the appropriate database user (this problem crops up often when dealing with database backups). If it is not, then you need to fix the mapping. Fortunately, there is a command called sp_change_users_login that you can use to fix this problem.
First, check if your login is mapped to your database user. Using SQL Server Management Studio (assuming SQL Server 2008), look under Security/Logins for UserSecure. If you see it in the list, double click on it and select User Mapping. From there, locate the database you are trying to connect to, and see if UserSecure is mapped to that database. If it is not, you may be able to fix it using the following command (assuming UserSecure is the name of both the login and the user):
EXEC sp_change_users_login AUTO_FIX, UserSecure
See MSDN for more info on sp_change_users_login:
http://msdn.microsoft.com/en-us/library/ms174378.aspx
One issue that has bitten me a few times:
If your stored procedure (or view) requires permission from a user (let's say userA), and the stored procedure calls another database's table or view (say viewB), it is not sufficient to just make a login on viewB's database, you must also explicitly grant userA permission to select/execute/etc. on viewB (which in turn requires a user on viewB's database)
So in your case, you may need to explicitly grant UserSecure execute permission on a stored procedure on an existing database referenced by the one you restored.
This may not be the most elegent fix, but I quit focusing on the one procedure and instead granted execute permission to the guest user on the entire DB. Since this is only running on my personal machine security is not an issue and it seems to have fixed the problem.
Know the problem all too well,
The ID of the user(name) will be different from the backed up database to the restored one. MSSQL stores the ID of the user and not the username (text), so the ID will be different (99% of the time) per machine and backup. So when the ID does not match you don't have access.
All you need to do is delete the user and recreate it, make sure you do it in both places:
Delete the user from the database first:
DATABASE -> SECURITY -> USERS -> Right click (username) + delete
Then goto
SECURITY -> LOGINS -> Right click (username) + delete
Then recreate the user and give the account the correct permissions and you're all good.
Lately there has been a problem running some of our reports in access. Last week(the beginning of the week) we tried to run a reports lets call it A and it kept giving us the log in prompt. Even when the correct user-name and password were entered the log in box would just keep reappearing until cancel was pressed.
I clicked the debug and checked the query. I then logged into the database it is pulling the data from with the same user-name and password and received no trouble. Around Wednesday A was working again, even though nothing was changed. This week A is working but another report B is doing the same thing..
Anyone have any idea what this could be? I'm thinking maybe someone else has the report open? Any help is appreciated.
EDIT: I have narrowed down the error to one linked table that is causing the login prompt. It seems it has the DSN setup but no database specified. So i just need to relink the table..Is there anyway to do this at the GUI level? Also should I leave this question up for future users or just delete it?
Was the login prompt from Access or from Windows? If from Windows, then I'd say that there was some sort of file permission or network access issue at hand. If from Access, then I would say that something in the SYSTEM.MDW that you are using is corrupt or has been reconfigured.
If the login prompt is from ODBC it probably means that the credentials that are being used to access the backend database (per your comments you mentioned it was SQL Server) are either invalid or disabled. (Or it could be as simple as the backend database is/was temporarily unavailable).
If you are using linked tables in Access to a SQL Server it means that an ODBC connection was created and you might try verifying that the ODBC connection is working ( Control Panel, Administrative Tools, Data Sources(ODBC) ). In that dialog there is a place to test the connection.
Background:
I have a site built in ASP.NET with Sql Server 2005 as it's database. The site is the only site on a Windows Server 2003 box sitting in my clients server room. The client is a local school district, so for data security reasons there is no remote desktop access and no remote Sql Server connection, so if I have to service the database I have to be at the terminal. I do have FTP access to update ASP code.
Problem:
I was contacted yesterday about an issue with the system. When I looked in to it, it seems a bug that I had solved nearly a year ago had returned. I have a stored procedure that used to take an int as a parameter but a year ago we changed the structure of the system and updated the stored procedure to take an nvarchar(10). The stored procedure somehow changed back to taking an int instead of an nvarchar.
There is an external hard drive connected to the server that copies data periodically and has the ability to restore the server in case of failure. I would have assumed that somehow an older version of the database had been restored, but data that I know was inserted 7 days and 1 day before the bug occurred is still in the database.
Question:
Is there anyway that the structure of a Sql Server 2005 database can revert to a previous version or be restored to a previous version without touching the actual data? No one else should have access to the server so I'm going a little insane trying to figure out how this even happened.
Any ideas?
Using SQL Server's built-in backup and restore mechanism, there is no means to pick only certain objects to restore. With transaction log backups, you can restore to a point in time which might be before a certain transaction or ALTER statement was made but that's the closest you get. There are tool's which will let you pick certain objects to restore however they work by either restoring the database to a copy and copying over the objects you want or reading the backup directly and copying out those objects. In other words, this is not something could have happened using the built-in tools accidentally. My guess is that someone accidentally ran an old script of the stored proc(s) that reverted it.
It would be trivial to change a stored procedure without touching any data, or any other stored procedure. How who why when, that's the problem.
One suggestion, run
select * from sys.procedures
and check the create_date and modify_date columns, for both your problem procedure and all other procedures in the database.
I've witnessed similar things happening with an app I have installed at one client location. Every so often the s'procs revert to an older version.
It's just one client, the app is installed at several others which have never had this issue, and they happen to be a school district as well. It happens about once every 3 months or so, and no one should be touching that machine. I'm not even sure they have anyone in house that would know how to open enterprise manager.
Out of curiousity, what backup software is your client using? and, after checking the creation / modify dates on the procedures, did a server reboot occur around that time?
The reason I ask is that my client has backup software that does some really weird things on that server. For example, on reboot it has to "play back" changes, including file operations, since the last successful backup. Also, is it installed in a VM?
Through Data Transformation Services (DTS) ? or if the scripts that set up the database are available someplace..