I have to deploy a SQL Server 2008 R2 from my development environment hosted on a Virtual Box VM to a brand new test server. Both servers use integrated Windows authentication.
Part of the problem was that the test server uses SQL Server 2008 (Express). I have managed to export schema creation scripts and raw data inside an Access database, but this is not the subject of the question: apparently the database was correctly imported on the target environment.
However, when I started the web site that depends on the exported database, I got some errors that does not appear when running in the development environment. After some research I found that the problem is caused by a little stored procedure.
This stored procedure creates a table on the fly that is dropped when no longer needed with a syntax like this one:
create table tmp_Codes (Code nvarchar(max))
When the test environment executes this statement the test environment effectively creates the table but it has the username attached to it, something like:
dbo.[NT AUTHORITY\NETWORK SERVICE].tmp_Codes
The subsequent code cannot find the newly created table and fails all operation on it.
I'll understand that this design is somehow broken, but I inherited this bunch of SQL scripts from a working environment and I cannot understand how this can work
Any ideas?
CREATE TABLE #tmp_Codes (Code nvarchar(max))
Sorry it was a very trivial error: the user NT AUTHORITY\NETWORK SERVICE has the default schema set to its name instead of dbo.
After changing the setting, the stored procedure worked as expected.
Related
I am trying to update an old script in a production installer so that it can work with both Azure SQL and SQL.
The problem is that our script is calling USE to switch the database. On prem we are creating the database, in Azure it will already be created for us... so we are detecting its existence and moving on. However that is where we are then calling USE to switch, for on prem.
I was hoping I could skip it like this in Azure
IF NOT SERVERPROPERTY('edition') = 'SQL Azure'
USE MYDB
I am still getting the "USE statement is not supported to switch between databases."
The hack is to put this into a string and run it with: EXEC sp_executesql
This works for most things, but I don't think it works with the USE statement.
Is there any way I can let the Azure SQL parser skip this section, as it will never be executed?
I am open to SQL based workarounds... but I am trying to avoid rearchitecting the installer.
USE statement is not supported to switch between databases
On Azure SQL Database this error only occurs when you try to 'USE' a different database.
In Azure SQL Database, the database parameter can only refer to the
current database. If a database other than the current database is
provided, the USE statement does not switch between databases, and
error code 40508 is returned.
USE (Transact-SQL)
Similarly three-part names referencing the current database are allowed.
I'm using a postgresql (9.6) database in my project which is currently in development stage.
For production I want to use an exact copy/mirror of the database-cluster with a slightly different name.
I am aware of the fact that I can make a backup and restore it under a different cluster-name, but is there something like a mirror function via the psql client or pgAdmin (v.4) that mirrors all my schemas and tables and puts it in a new clustername?
In PostgreSQL you can use any existing database (which needs to be idle in order for this to work) on the server as a template when you want to create a new database with that content. You can use the following SQL statement:
CREATE DATABASE newdb WITH TEMPLATE someDbName OWNER dbuser;
But you need to make sure no user is currently connected or using that database - otherwise you will get following error.
ERROR: source database "someDbName" is being accessed by other users
Hope that helped ;)
I have an application that uses EF Code First against a SQL Server 2012 database. I'm using the DropCreateDatabaseIfModelChanges initializer.
I have a database on my development machine that I want to move over to my testing machine, and to do that I'm attempting to use backup/restore. Unfortunately, having done that, I get the dreaded "Model compatibility cannot be checked because the database does not contain model metadata" error.
I don't understand why this is the case - the database works OK on my dev machine. Is it not possible to transfer the database to another machine?
Solved: the issue was that the __MigrationHistory table, while present, was not accessible to the application because of insufficient database privileges. I (temporarily) made the user a DBO on the database, and it all worked fine. (Hat tip to Jayantha).
Now the metadata table is removed from the code first DB and added the __MigrationHistory table to system tables. You can try running Enable-Migrations command in Package Manager Console. Here is more details .
I need to make some changes to an existing app that is running fine on my hoster. I download the database and can open it in Visual Studio for development and testing, but my localhost will not let me use the stored procedures that are there: "Could not find stored procedure xyz". I have made no changes yet, I want to make sure I have a fully functional environment before I start doing things.
The stored procedures are there -- I can see and use them all in SSMS.
I think I have permissions set correctly via SSMS, but I don't do this very often can easily have missed something somewhere. What do I do now? My connection strings for local vs hoster are identical, except of the server name.
Are you sure that the login for the DB is finding the correct database? Each login has a default database that it will look in for executing queries when the objects are not fully qualified. So if you are calling ProcName or dbo.ProcName in MyDatabase but the login has a default database of "master" then you can get that error. Either fully qualify the objects (not a bad idea anyway) or update the settings for the login to have the correct default database.
I've got a project where I'm attempting to use SQLite via System.Data.SQLite. In my attempts to keep the database under version-control, I went ahead and created a Database Project in my VS2008. Sounds fine, right?
I created my first table create script and tried to run it using right-click->Run on the script and I get this error message:
This operation is not supported for the provider or data source you are using.
Does anyone know if there's an automatic way to use scripts that are part of database project against SQLite databases referenced by the databases, using the provider supplied by the System.Data.SQLite install?
I've tried every variation I can think of in an attempt to get the script to run using the default Run or Run On... commands. Here's the script in it's most verbose and probably incorrect form:
USE Characters
GO
IF EXISTS (SELECT * FROM sysobjects WHERE type = 'U' AND name = 'Skills')
BEGIN
DROP Table Skills
END
GO
CREATE TABLE Skills
(
SkillID INTEGER PRIMARY KEY AUTOINCREMENT,
SkillName TEXT,
Description TEXT
)
GO
Please note, this is my first attempt at using a Database, and also the first time I've ever touched SQLite. In my attempts to get it to run, I've stripped any and everything out except for the CREATE TABLE command.
UPDATE: Ok, so as Robert Harvey points out below, this looks like an SQL Server stored procedure. I went into the Server Explorer and used my connection (from the Database project) to get do what he suggested regarding creating a table. I can generate SQL from to create the table and it comes out like thus:
CREATE TABLE [Skills] (
[SkillID] integer PRIMARY KEY NOT NULL,
[SkillName] text NOT NULL,
[Description] text NOT NULL
);
I can easily copy this and add it to the project (or add it to another project that handles the rest of my data-access), but is there anyway to automate this on build? I suppose, since SQLite is a single-file in this case that I could also keep the built database under version-control as well.
Thoughts? Best practices for this instance?
UPDATE: I'm thinking that, since I plan on using Fluent NHibernate, I may just use it's auto-persistence model to keep my database up-to-snuff and effectively in source control. Thoughts? Pitfalls? I think I'll have to keep initial population inserts in source-control separately, but it should work.
I built my database using an SQLite SQL script and then fed that into the sqlite3.exe console program like this.
c:\sqlite3.exe mydatabase.db < FileContainingSQLiteSQLCommands
John
Well, your script looks like a SQL Server stored procedure. SQLite most likely doesn't support this, because
It doesn't support stored procedures, and
It doesn't understand SQL Server T-SQL
SQL is actually a pseudo-standard. It differs between vendors and sometimes even between different versions of a product within the same vendor.
That said, I don't see any reason why you can't run any (SQLite compatible) SQL statement against the SQLite database by opening up connection and command objects, just like you would with SQL Server.
Since, however, you are new to databases and SQLite, here is how you should start. I assume you already have SQLite installed
Create a new Windows Application in Visual Studio 2008. The database application will be of no use to you.
Open the Server Explorer by pulling down the View menu and selecting Server Explorer.
Create a new connection by right-clicking on the Data Connections node in Server Explorer and clicking on Add New Connection...
Click the Change button
Select the SQLite provider
Give your database a file name.
Click OK.
A new Data Connection should appear in the Server Explorer. You can create your first table by right-clicking on the Tables node and selecting Add New Table.