I'm getting this error when trying to deploy a SQL Server Data Tools (SSDT) database project:
View or function 'dbo.Employees' has more column names specified than columns defined.
I deleted a column from the underlying table and the view looks like this:
CREATE VIEW [dbo].[Employees] AS SELECT * FROM [$(ExternalDB)].[dbo].[Employees];
Doing a Google search brings back this page which says that SQL Server keeps meta data on views which must be refreshed. They mention this command:
EXEC sp_refreshview 'Employees';
If I put that in the pre-deployment script, it'll run before the column was dropped. If I put it in the post-deployment script, the deployment will throw the error before it gets executed. So my question is where or how can I do that with an SSDT project?
This is interesting as by default ssdt will refresh any views which depend on any table that has changed as part of a deployment.
Was the column dropped as part of a normal ssdt deployment?
In your publish profile or publish options are you setting ScriptRefreshModule to false?
Aside from this select * in a view is bad practice, put the full column list and this problem disappears, you can even right click the "select *" and choose to expand to get the full column list - do that instead :)
Ed
Related
I decided to use int instead of DateTime at this stage. I created a migration with add-migration, but that failed and said I have to run CONVERT command manually. I don't know SQL Server, so I went to the Visual Studio Server Explorer and used the Table design tool to change the values to int and ran Update. It succeeded, however, when I try to save something to my database it throws an error:
System.Data.SqlClient.SqlException: 'Cannot drop database "AppDbContext" because it is currently in use.'
I deleted manually the database files, located in my App_Data folder and rebuilt my app, but same error occurs. When I check the table structure with the design tool, it reflects my changes - the desired column is now int instead of DateTime.
This is the code that accesses the database:
db.Contests.Add(contest);
Contests is indeed the table I changed, but the database structure seems alright. I don't understand why it attempts to drop the database. How can I fix it?
Summary
Always work at Database level when modifying tables - I installed and used SQL Server Managment Studio and changed changed the tables with it successfully.
Error
As per my Cannot drop Database error, it happened, because my DbInitiallizer class was set to drop and re-recreate the database each time the model is changed. I removed that setting and instead configured it to create the database only if it does not exist. Afterwards all I needed to do was run the migration, to notify EF that all the table is now modified to reflect my models and it worked.
Simple steps to change table column property:
Make the desired model changes.
Use SQL Server Management Studio or similar database-level tool to modify the table column
Run add-migration <Name> and update-database in Package manager console tool in Visual studio
Done :)
I have a database project in SSDT and when I import a view that references objects in a different database, I get error SQL71561, with a description along these lines:
Error 4 SQL71561: View: [schema].[viewname] has an unresolved
reference to object [other_db].[schema].[table].[column]
I spent some time trying to figure this out, so to help others running into this I will post the answer that worked for me.
To resolve this, I added a reference to the other database, clearing out the "Database variable" field in the dialog. If I didn't clear this field, when doing a schema compare, SSDT would generate the update script using the database variable name, which would fail.
Add a Database Reference to the project.
In my case the other database was another project in the same solution, so I was able to select it in the first drop down on the "Add Database Reference" dialog.
Make sure the text in the "Database name" field is correct.
Clear out the "Database variable" field.
Look at the "Example usage" text and verify that it looks as expected. Click "OK" to add the reference and that should take care of the 'unresolved reference' errors.
After doing this, I was able to do a schema comparison, but trying to build the project produced the following error:
Error 408 SQL00208: Invalid object name 'db.schema.table'.
Going to the project properties and unchecking "Enable extended Transact-SQL verification for common objects" allowed the project to build successfully.
My problem was from a view. In the view I had...
...FROM [MyDatabase].[dbo].[MyTable]
I replaced it with...
...FROM [MyTable]
The reason is that you may be importing the bacpac/dacpac into a different database name so the reference to [MyDatabase] might not be valid.
You can run into this if your build order is incorrect.
I ran into this when pulling a fresh copy of a project from source control and doing "build solution".
If a reference is not working, make sure you build the referenced database [other_db]. Once I built the [other_db] my references worked.
These errors started appearing for me when I changed the Project Properties > Target Platform from SQL Server 2016 to SQL Server 2014.
In my scenario I have a database that is created by an external tool in one SSDT project (A) and my SQL views, etc in another project (B) with a reference from B->A.
Having developed against SQL 2016 I found our test environment was running 2014 so changed the target platform in (B) so I could deploy. (A) isn't deployed - the external tool is also installed and configured to produce the same database.
Strangely, I was later able to alter views in (B) and publish, but then wanted to remove a column. At this point the publish kept failing due to these reference errors. Changing the Target Platform on project (A) to 2014 then cleared the error and allowed me to proceed.
After trying all the above four answers I was still getting same error for two of my stored procedures.(From 1000+ errors to just 2 )
So what worked now is, I simply replaced the table alias name with the table name itself and hoila the build succeeded.
--From
table1 t1 join table2 t2
t1.col1 = t2.col1
--To
table1 t1 join table2 t2
table1.col1 = t2.col1
None of above solutions works for me.
But this one:
and change those script that refer to other database project.
for example if you have a view in AdventureWorks that refer to AdventureWorksDW, use this syntax:
select * from [$(Your Database Variable)].Schema.Object
e.g.
select * from [$(Your Database Variable)].dbo.dimDate
I have a number of views in my SQL Server database.
How do I export these as CREATE VIEW scripts?
I tried to right click the database - script database as - create to - new query editor window, but it doesn't show my my views (or tables even for that matter).
Any ideas?
In SSMS, if you right click the DB -> Tasks -> Generate Scripts... - that will take you through a wizard.
You can run through the wizard and select your DB, then the views as AdaTheDev mentioned or you can right click on each query and generate a script directly.
I prefer another way, because always I edit the views to remove "not necessary script generated SQL syntax" (depends on the point of view :)).
Right click the view, Generate script, CREATE in, new window.
See screenshot below (sorry for german version, but should work anyway).
I tried to right click the db - script database as - create to - new query editor window, but it doesn't show my my views (or tables even for that matter).
The purpose of the menu you mentioned is only to create the empty database, without any tables, views or anything else.
If you want to script anything beyond the empty database, you have to use the wizard already mentioned in AdaTheDev's answer.
Maybe you receive empty page because source of VIEW was encrypted or removed.
In older SQL editions there was a trick - after creating VIEW (SQL Server compiled it) developer could remove source of VIEW statement to protect it from "deassemblation". In current editions there is possibility to encrypt source of VIEW statement.
I am using SQL Server 2008 Express and Sql Server Management Studio 2008.
I am trying to associate a database table with a new schema.
I have created a new Schema by navigating to Security->Schemas in object explorer. I right clicked on the folder and created a new schema called 'People' and set the owner as db_owner. This new Schema now appears in object explorer.
I would now like to associate a table with this schema. I open the table in design view and click on the drop down list in the table Properties pane which contains the available schemas but my newly created schema is not visible.
I have tried refreshing everything throughout object explorer. Closing design view and reopening etc. but still it isn't there.
Am I doing something wrong?
Can anyone point me in the right direction please?
Sorted... in the most ridiculous way.
Apparently refreshing object browser at every hierarchical level is not sufficient.
I had to CLOSE sql management studio, then re-open it. The list of schemas had then managed to refresh and would allow me to associate my new custom schema with the table.
IMO this is rubbish.
Step 1:
Open New Query(or existing query window). Ctrl+Shift+R in query window. It will refresh the intellisence cache or
Edit > IntelliSense > Refresh Local Cache
Also check if IntelliSense is enabled in
Tools > Options > Text Editor > Transact-SQL > Enable IntelliSense
Step 2:
refresh F5 the Object Explorer.
it worked for me
Similar Answer on stack overflow
I am not following you when you say "open the table in design mode then click on the drop down list". I must be overlooking the list on my SQL Express.
Have you tried to change the schema via TSQL? The command is short:
ALTER SCHEMA "target schema" TRANSFER "source schema"."table name";
GO
Replace target and source schema with your schema names.
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.