When I try to generate a BACPAC from a database running on a local MSSQL database I get an error:
One or more unsupported elements were found in the schema used as part of a data package.
Error SQL71564: The element Extended Property: [dbo].[EnabledCompany].[MS_DiagramPane1] is not supported when used as part of a data package (.bacpac file).
Error SQL71564: The element Extended Property: [dbo].[EnabledCompany].[MS_DiagramPaneCount] is not supported when used as part of a data package (.bacpac file).
(Microsoft.SqlServer.Dac)
[EnabledCompany] is a simple view made up of a select from a single table with a single where filter based on a bit column. (It only shows companies where IsEnabled == true).
I'm using SQL Server 2014 with the latest version of the tooling (SSMS).
One workaround for this is to delete the extended properties on the view.
This will then allow the database to be exported.
However, it will break the graphical designer for the view in question and so isn't ideal.
Related
I have a regular SQL Server view that refers to the planar spatial data type, geometry. When I import this database view into my SSDT project, it throws the following exception:
SQL70561: Cannot schema bind view 'MyView' because name 'geometry' is
invalid for schema binding. Names must be in a two-part format and an
object cannot reference itself.
It seems like the type geometry is not recognized by my SQL Server Database Project in Visual Studio. My target SQL Server version is 2016.
Here's the Visual Studio screenshot:
TIA
It took me two days to figure it out. So, whenever we have a view containing the clause WITH SCHEMABINDING it is forced to bind the schema for everything included in the PL/SQL block. In my case, it was trying to look under dbo and couldn't find geometry there. So, once I specified system schema sys in front of the geometry, it was accepted.
Hopefully, it helps someone in the future.
I am using Visual Studio enterprise 2017 (Version:15.71.1) and SSDT(Version:15.1.61804.210)
and also using TFS to keep my code. In my database project all tables are temporal table.
Now when i am changing column type or column name in TFS , i am not able to build my project so not able to generate publish script.
I am getting error :
Error SQL71609: System-versioned current and history tables do not have matching schemas. Mismatched column:"XXXXX"
Do we have any solution for this ?
Generally you can try explicitly defining the history table, then manually keep the schema of the current and history table in sync.
Reference this thread: Avoid schema mismatch in System-Versioned tables
UPDATE:
As you mentioned the solution which worked for you is to make these changes in SQL Server Object Explorer (You can see it by right clicking on DB project and choosing the “View in Object Explorer” option). You need to do the modification here and just save it and it will work.
The solution which worked for me , is to make these changes in SQL Server Object Explorer (You can see it by right clicking on DB project and choosing the “View in Object Explorer” option). You need to do the modification here and just save it and it will work.
I'm using SQL Server Data Tools (SSDT) to manage my database project but I don't seem to be able to populate a FULLTEXT STOPLIST.
CREATE FULLTEXT STOPLIST [MyStopList] FROM SYSTEM STOPLIST;
SQL70010: A FROM clause is not supported for CREATE FULLTEXT STOPLIST statement
I'm using the latest version of Visual Studio 2015 and SSDTs.
Is there any way round this?
I'm having the same issue. Trying this in a post deploy script results in the same error. The FROM keyword gets underlined in red even before building the dacpac.
Just found this link with MS response.
https://social.msdn.microsoft.com/Forums/en-US/3d89831e-43d8-4fe5-8ca5-d604a93789cb/sql70010-a-from-clause-is-not-supported-for-create-fulltext-stoplist-statement?forum=ssdt
"There is no support for the FROM clause. Because the from clause references a stop list definition that is not in the project, SSDT has no way of understanding the stoplist without the referenced database. This is one example where the declarative model limits some of the supported TSQL syntax as if the elements in the database are not completely defined in the project or referenced projects, SSDT cannot model them correctly in the project system."
I am looking at a sql server database for a tfs 2010 install and I am trying to find bugs/files logged by date.
Is this information contained in the database?
I see other information such as a view named WorkItemChanges which shows all the stories that have been changed by date.
* Directly querying the collection database is unsupported *
The Tfs{YourProjectCollection} database contains all work items for a specific project collection. They live in the different Work Item tables, since a bug is a specific type of work item.
If your TFS environment is configured for reporting using Report Server, then you can use the Analysis cube or the TFSWarehouse databases to query this kind of information. For work items, a limited set of fields is stored and the same goes for files in source control. You should at least be able to find out which have changed. The following doc describes the warehouse structure: Creating, Customizing and Managing reports for Visual Studio ALM. A quick way to get started is from the Excel Powerpivot reports which are installed to your team project by default if your TFS instance is connected to a Sharepoint server with teh appropriate features enabled.
* You have a number of alternatives *
I suppose that your Visual Studio is currently working, if that's the case then there is no need to use a SQL query to get to the information you're after.
To query all bugs (or other work item types) that have changed between two dates, create a work item query (in Visual Studio) that looks like this:
You can import these into Excel for easy manipulation or further aggregation. And you can even quickly create a Report from that. More information can be found in the Bulk Add or Modify work items in Excel.
To query all files changed between a specific date range, is a little harder. You can quickly get all changesets between two dates using the commandline using tf history $/Project /collection:yourprojectcollectionUri /recursive /version"D2012-10-10~D2013-10-10" this will popup window with all changesets between these dates. You can specify /noprompt /format:detailed to dump all details to the command prompt window.
Alternatively, you can do a folder diff between two dates. This can be done from the UI in the Source Control Explorer. Or from the commandline using tf diff or tf folderdiff
I am using Visual Studio 2008 Database Project GDR2 to manage multiple databases and I am getting a number of errors related to synonyms.
Project-A has a reference to Project-B because Project-A has a number of synonyms to tables in Project-B. The full error I'm getting is "TSD04105: The model already has an element that has the same name dbo.[OBJECT]". This always points at the synonym.
The issue seems to be that the synonym on Project-A has the same name as the table on Project-B. Obviously I could rename all my synonyms so that they have different names than the tables, but this introduces a LOT of work on my part (there's over 140 synonyms so far).
Removing the reference to Project-B will get rid of that error, but instead all of my stored procedures in Project-A generate errors because it can't reference the tables in Project-B any more.
Is there a way to fix this problem short of renaming all the synonyms? What is the appropriate way to handle this situation in the Database Project?
I had this issue between a 2008 server project and a database project and I solved it by using a literal Database Variable Value.
Referencing project properties -> References Tab -> Database Variable Value
I would say that you could also use a Database Variable Name/Value pair as well.
At my previous employer we prefaced each item with item type.
syn_BeerName
vw_BeerName
tblBeerName
Usually, synonym to view, view to table.