In a project on which I am performing maintenance, I am referencing a database stored on another server. This reference was previously pointing at a database on the same server, but my testbed server isn't large enough to store both databases, so I'm having to refer back to the live database.
Anyway, whoever created this application made use of SQL Views, and I have found that when trying to edit the view, that it cannot reference an external database.
The existing reference is to myDatabase.dbo.tableName. When I try to change that to [MyServer.com].myDatabase.dbo.tableName moving away from the editor removes all of the square brackets, leaving me with MyServer.com.myDatabase.dbo.tableName which is not a proper table reference.
Any ideas what I can do to fix this?
It looks like you have added a linked server with the name "MyServer.com" I suggest you rename this to something without the dot, MyServerCom would be fine. Its ok if the details in the linked server point to a server that happens to be at that address.
Then the four part name can be MyServerCom.myDatabase.dbo.tableName
Don't edit the view definition in Enterprise Manager - use query analyser to script the view for ALTER, make the appropriate changes, and then run the script.
Enterprise manager does some fairly nasty things. I'd similarly recommend scripting an ALTER rather than using the "Design" option if you're using SSMS to manage your server/database.
Related
I am attempting to create a new database in an existing sql server from code first. I used package manager to enable migrations, add a migration, then update database. The three methods executed without any errors and I got the traditional massages afterwards. However, when I look in either MSSSMS or Server Explorer I don’t see the database. I tried re-running the update database command and got the migration has already been applied. Any suggestions?
Update:
I've figured out that the project is adding the database to localdb. However, I have a connection string in the app.config file.
Probable causes are:
the database was never created
you use a login that can't see the database. Using Windows authentication/sa might allow you to see it and create user mappings for other logins.
you have multiple instances of sql running and you're connecting to the default instance while the database what created on a named instance
you accidentally created the database on another server
you connect to master by default with your software and instead of creating a database the database structure was created in the system database master
I've been working with MS sql for more than a decade and have struggled with issues like these, but in the end I could always explain what happened; if SQL returns it executed a query succesfully id did.
I'm trying to determine the best way of creating a blank copy of a SQL Server 2012 database, renaming it & placing it on the same server instance. I could restore/rename a backup copy, and then delete all the data, but there are quite a few tables/views, stored procedures, triggers, etc.
Are there any drawbacks with the "generate scripts for database objects" wizard? Just trying to figure out the most efficient way to create a blank copy & would appreciate anyone's experience/wisdom on the topic.
I am running a SQL Server 2012 Enterprise edition. We have a database that our colleagues like, so we are planning to create a copy & populate with their data instead of our data.
Go to Object Explorer ,Right Click the database you want to create a blank copy of.
Right Click --> Tasks --> Generate Scripts
Select the entire Database, you also have the option to select specific objects, In advance option select schema only.
I would prefer this method over any other, as Restoring a Copy of database and then deleting data means doing a lot of work which was never required to begin with. Backing up data that was never required, restoring unwanted data and then finally making sql server to delete it, a lot of unnecessary work.
Another reason why scripts are better over other options, These scripts will use fresh pages to write all of this data. Imagine you having to write something on a brand new note book as compare to a note book where you had to erase first and then use it to write data on it.
I've created an SQL Server Database Project so that I can capture my database schema and add it to source control.
My problem is that the database contains Views which reference external databases. Given the business and project environment, this is an acceptable solution in the short tomedium term.
Sadly, this stops the database project from compiling, (since it don't contain the external database tables).
What are my options for getting around this error? I'm currently storing the schema in a single generated script, which is a pain to update.
Look at creating dacpac files out of the external databases and add them as database references. I did that by using the SQLPackage command line to generate the file, put the files in a "shared" folder (optional, but useful if this pattern persists with other projects), then add a database reference to the project. I recommend removing the variable for the DB name unless it can change in different environments. I blogged a bit about this here:
http://schottsql.blogspot.com/2012/10/ssdt-external-database-references.html
Now if it's a truly breaking change, I've done this through post-deploy scripts. Drop/recreate the view and reapply any permissions necessary. That's not ideal, but it can work.
I need to include a Stored Procedure in Visual Studio 2013 which references another Database which is not part of the solution. I only refer to a very small portion of the external database which is itself big and complicated.
I know I need to add a reference to it so that I don't get warnings when referring to objects within the external database from within the Stored Procedure.
Adding that Database to a this or another Solution is not an option as its not part of our solution and importing that creates a whole variety of other issues.
I can see in older versions of Visual Studio that I need to create a schema file using VSDBCMD but this has been replaced by SQLPackage, but I can't see how to access that and whether it will need the external database anyway.
I've been going round in circles on this, so some pointers would be warmly welcomed.
I realize I am late to the party on this but perhaps it will still be useful to someone: You don't mention if this is a c# project or a database project.
I'll assume database as I not sure how you'd get errors otherwise on the internals of an SP.
The only way I know of to remove errors on cross-database references is to add the other database as a project in the database solution, add a database reference to the project with the sp, and then instead of using Database.schema.table syntax in the sp change it (in the database project) to [$(database)].schema.table
Alternately, a DACPAC can be created on the referenced database and used instead of referencing the database in an added project.
I'm new to this stuff myself, but I work with a lot of database cross-references in my sps so I am working through how to address this in database projects
I'm new to using SQL Server 2008 DB Project's in VS 2010. I found a good intro to setting them up. It's nice how they create Tables, Stored Proc's etc as objects. But is it also a limitation?
I want to use this project to manage 1 stored procedure (for learning). I do not want to import the entire database because 90% of the database is stuff we do not manage.
I created a new project without doing the import process. I then added a new stored procedure. Now I am having difficulty getting the thing to build. I'm getting various errors saying that I have unresolved references to objects.
How can I add a new stored procedure..build it and deploy it to the database? Is it possible with this kind of SQL project or do I need to drop back to the old, simple type of SQL projects that VS 2008 and below used?
Update
According to another post, support for the Database Project type is gone. Support for my situation appears to have been erased.
UPDATE 2 3/21/2012
I installed MSSCCI which allows me to use SSMS directly with TFS 2010. I no longer needed and found the setup process to be unmanageable for a large database SQL 2008 project. Especially when you only manage a small % of the DB.
You can Partition a Database Project by Using Partial Projects. This allows the database project to know the entire schema of the database, at the same time, you need not maintain the entire schema. You can work with the subset of the database that's under active development, for instance (or the subset which is your responsibility), yet the project knows the entire schema. This permits it to create change scripts at deployment time, by comparing the schema in the project with the schema in the target database.
You must import all schema objects referenced by your new stored procedure. But this can become a large task because every referenced object need all it's references too.
More trouble with linked server objects.