When scripting a SQL Server 2000 database, on an SQL Server 2000 version of SQL Server, with SQL Server Management Studio 2008 R2 (10.50.1617.0) i get the error:
Creating a user without an associated login is not supported in SQL Server 2008 R2.
With the full stack trace:
Microsoft.SqlServer.Management.Smo.SmoException: Creating a user without an associated login is not supported in SQL Server 2008 R2.;
at Microsoft.SqlServer.Management.SqlScriptPublish.GeneratePublishPage.worker_DoWork(Object sender, DoWorkEventArgs e) at System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs e)
at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)
What is a good way to resolve this issue.
i've considered:
creating a login (and incur the wrath high atop the thing)
deleting the user (and incur the wrath from high atop the place)
select some rather than all objects to script, and don't script the user that offends SQL Server 2008 R2
But i'll let people on SO post answers, get answers upvoted, and accept an answer that best solves the problem.
As instructed. Just don't script the database users that have no associated login. You can do this in the Tasks > Generate Scripts wizard (pointing 2008 or later SSMS at your 2000 instance) by choosing to select specific database objects and unchecking any troublesome users:
I suspect that your SQL Server 2000 database has user aliases: these were required in SQL Server 6.5 in some circumstances because it was, er, crap,
Note what MSDN says:
sp_addalias is provided for backward compatibility. Microsoft® SQL Server™ version 7.0 provides roles and the ability to grant permissions to roles as an alternative to using aliases.
Run sp_helpuser on the SQL Server 2000 box and review the output and remove them
Related
As the title says, I need to restore a SQL Server 2012 database (express) to a SQL Server 2008 R2 production database.
I cannot find a way to do so.
The scripting seems to fail due to the size of one of the tables having about 300.000 records.
Any way to "downgrade" the 2012 database?
Thanks
Michael
You CANNOT do this - you cannot attach/detach or backup/restore a database from a newer version of SQL Server (2012) down to an older version (2008 R2) - the internal file structures are just too different to support backwards compatibility. There's no way, no trick, no hack, no magic to make this happen. Period.
You can either get around this problem by
using the same version of SQL Server on all your machines - then you can easily backup/restore databases between instances
otherwise you can create the database scripts for both structure (tables, view, stored procedures etc.) and for contents (the actual data contained in the tables) either in SQL Server Management Studio (Tasks > Generate Scripts) or using a third-party tool
or you can use a third-party tool like Red-Gate's SQL Compare and SQL Data Compare to do "diffing" between your source and target, generate update scripts from those differences, and then execute those scripts on the target platform; this works across different SQL Server versions.
I have been using this connection string with no problem on a number of databases and MS operating systems. Windows Server 2003, 2008 R2 and 2012 R2 Eval, all Express versions.
I am now trying to deploy to a new Windows Server 2012 R2 installation and I am getting some errors. I have the SQL Server 2008 R2 installation on the Windows Server 2012 R2 machine.
My con string:
connectionString="Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\myDB.mdf;Integrated Security=True;User Instance=False" ProviderName="System.Data.SqlClient"
I think this must have something to do with the installation sequence of the components on the new server.
I have in the past been able to simply copy myDB.mdf to basically any web server and open or access the DB tables. This DB includes an ASP membership for the web site that it is tied to.
Here is the error:
CREATE DATABASE permission denied in database 'master'. An attempt to
attach an auto-named database for file
C:\inetpub\techTran\App_Data\myDB.mdf failed. A database with
the same name exists, or specified file cannot be opened, or it is
located on UNC share.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.Data.SqlClient.SqlException: CREATE
DATABASE permission denied in database 'master'.
I thought I understood what this error was. I have checked permissions and they match the other servers where this database has been deployed. My SQL Server installations are basically all the same. The only difference here is that this is Windows Server 2012 R2 on a VM. Or I did not install the SQL Server 2008 R2 the same way I have done in the past 5 servers I have set up. (Which I am guessing is probably the case.)
UPDATE: Uninstalled and reinstalled SQL Server and SSMS.
I know there is only one database name on the server called myDB.mdf, so I don't believe the "same name" portion of error. I have added security to the db so that it can be opened and I even installed Visual Studio 2012 on the server to be certain that the db could be opened. I can run the full app on the localhost (server 2012) but I can not access it over a web connection.
I believe the specific error message relating to
CREATE DATABASE permission denied in database 'master'
is the issue.
I have never seen this error before.
I typically assign NETWORK SERVICE account to the database to allow access and this is how this one is set up as well. I also thought this might be a connection string issue. But this same string has worked on 4 different servers now with no changes. Server 2003, 2008 R2, and 2012 (demo platform)(all Express versions), now in production this is failing.
The home page loads and then the login throws the above error.
Your connection string says AttachDbFilename=|DataDirectory|\myDB.mdf. Well, your path must have changed in one place (SQL Server) and not the other (app configuration). AttachDbFilename will try to create a new DB if it can't find that file. That's probably your error.
As an aside, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 all have differences, especially with security and in particular with how SQL Server behaves, but you keep using them interchangeably. That makes it very confusing to tell what's going on. Also, your connection string says Data Source=.\SQLEXPRESS. Is this SQL Server Express? Because that has important differences with most other editions of SQL Server, too. More recent editions are very similar to Standard edition, but the older the edition, the more quirks it has. They're generally considered different beasts.
SOLVED: I am not sure how this happened or perhaps why it didn't happen. But for some reason the installation of SQL did not add the NETWORK SERVICE account to the sysadmin Server Role. I cross referenced this with the SERVER 2003 installation where SQL 2008 R2 is also running, and discovered that the sysadmin SQL Server Role included NETWORK SERVICE in my correctly functioning environment. So once I added the user account to this role, everything came up fine.
I believe this might have been an issue during the installation of SQL 2008 R2. I did specify NETWORK SERVICE, but for some reason it was not provided the role.
Has anyone connected Adempiere (ERP) (or any PostGreSQL db) to SQL Server 2012 Express?
There used to be an IT manager to help me out with this, but now i'm left alone with this.
I downloaded the free Sql Server 2012 Express and wanted to use the SSRS for Adempiere. It seems its running on the SQL Server 2010 for SSRS.
I have already added the ODBC Data Sources for 32 Bit. My computer is using 64bit, is there any incompatibility? I'm not sure if my server is 32 or 64bit.
I've tried following the instructions on http://postgresblog.blogspot.com/ but to no avail.
I already have Crystal Report running, so i'm sure its possible to run 3rd party software for Adempiere.
Anyone knows how i can use SSRS for Adempiere? Thanks!
Since you're using Express edition, if you're trying to connect to any Data Source other than an database on the same SQL Server instance it won't work.
See Features Supported by Reporting Services in SQL Server Express.
From that article:
Report data sources must be SQL Server relational databases that run
locally in SQL Server Express.
Also:
Analysis Services, Oracle, XML, SAP, SQL Server Integration Services
(SSIS), OLE DB, and ODBC data sources are not supported.
You're going to need a different edition to connect to an ODBC Data Source.
I have a backup of a database (.bak) created in SQL Server 2008 R2.
To test some features, like to import this backup to LocalDB (2012).
When I click on Restore and select the database the following error occurs:
Property MasterDBLogPath is not available for Information 'Microsoft.SqlServer.Management.Smo.Information'. This property may not exist for this object, or may not be retrievable due to insufficient access rights. (Microsoft.SqlServer.Smo)
You need to add the following 3 registry keys (run/regedit):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL11E.LOCALDB\MSSQLServer\DefaultData,
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL11E.LOCALDB\MSSQLServer\DefaultLog,
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL11E.LOCALDB\MSSQLServer\BackupDirectory
With an existing folder name as value (where you have write access), e.g. "C:\Databases".
Please have a look at the excellent walkthrough under http://www.roelvanlisdonk.nl/?p=2896 (which is where I have copied the answer from).
SQL 2008 R2
The below is all being performed within SSMS
I have a Db that sat on a Dev server quite happily and everything ran peachy as sysadmin with sql authentication account.
This code has been migrated to a test box where a reduced permission set exists on the dbo schema, where users have been allocated read/write and execute on the schema through Windows authentication.
Here's where the fun starts, when I run certain stored proc's they show as succesful but error logging on the procedure advised that it cannot see certain tables or it does not have the appropriate permissions to do so.
Oddly though despite all the tables currently sit on the same schema, the same issue is not seen on all others tables.
If I elivate the permission to Db Owner, then the issue disappears completely.
Has anyone else come across this issue before and if so how did you get around it?