I'm getting a strange error when exporting an Azure SQL Database. Exports had been working fine until some recent schema changes, but it's now giving me Error SQL71501.
The database is V12, Compatibility Level 130 (although the master database is still Compatibility Level 120).
The problem seems to be caused by a new table-valued function, which uses the built in STRING_SPLIT function. There were already stored procedures using STRING_SPLIT and they don't seem to have affected the export, but the function (which compiles OK, and is working fine) seems to cause a problem with the export.
The function below is a simplified version of the real one, but causes the same problem.
CREATE FUNCTION [dbo].[TestFunction](
#CommaSeparatedValues VARCHAR(MAX)
)
RETURNS TABLE
AS
RETURN
SELECT c.ClientId,
c.FullName
FROM dbo.Client c
INNER JOIN STRING_SPLIT(#CommaSeparatedValues, ',') csv
ON c.ClientId = csv.value
The complete error message given in the Import/Export history blade is as follows:
Error encountered during the service operation.
One or more unsupported elements were found in the schema used as part of a data package.
Error SQL71501: Error validating element [dbo].[TestFunction]: Function: [dbo].[TestFunction] has an unresolved reference to object [dbo].[STRING_SPLIT].
Error SQL71501: Error validating element [dbo].[TestFunction]: Function: [dbo].[TestFunction] contains an unresolved reference to an object. Either the object does not exist or the reference is ambiguous because it could refer to any of the following objects: [dbo].[Client].[csv], [dbo].[STRING_SPLIT].[csv] or [dbo].[STRING_SPLIT].[value].
This is Xiaochen from Microsoft SQL team. We are already working on the fix of this issue. The fix will be deployed to the export service in next few weeks. In the same time, the fix is already available in the latest DacFX 16.4 (https://blogs.msdn.microsoft.com/ssdt/2016/09/20/sql-server-data-tools-16-4-release/). Before we fix this issue in the service, you can download the DacFX 16.4 and use sqlpackage to work around.
SQLAzure validates Schema,references of the objects when you export database,if any of the references fails like the below one in your case
Error SQL71501: Error validating element [dbo].[TestFunction]: Function: [dbo].[TestFunction] has an unresolved reference to object [dbo].[STRING_SPLIT].
the export won't succeed..So you will need to resolve those errors,prior to export..
From the docs,you will need to set the compatibility level to 130
The STRING_SPLIT function is available only under compatibility level 130. If your database compatibility level is lower than 130, SQL Server will not be able to find and execute STRING_SPLIT function
Update:
I was able to repro the same issue and only current workaround is to delete the table valued function,that is referencing system function and export DACPAC,once export is done,recreate the table valued function :(
I have raised the issue here:please upvote..
https://feedback.azure.com/forums/217321-sql-database/suggestions/16722646-azure-database-export-fails-when-split-string-is-i
Data Migration Assistant did it for me. First run an assessment on the schema, on success, run your migration https://www.microsoft.com/en-us/download/details.aspx?id=53595/
Related
I have very basic skills in developing SSIS packages; and getting errors while developing this new package. With this package, the SQLInstance is getting determined fine as can be seen in column mapping in the second picture. But it is not reading columns from the columns of a user table (IndexType column, in this case). This is the issue.
Tried below steps with no luck till now:
I set the VaidateExternalMetaData setting to False, still same error.
Already removed all columns one-by-one to identify whether it is issue with some specific data type, still same issue.
Created a brand new test package, same error in test package also.
Another package working fine in production with same settings with a user database. Copied the DataFlowTask component from it and used it new package, still same issue.
Please help. Many thanks.
It may be SQL server version. I had similar issue when using table variables or temp tables. You need to use with result set, similar to this:
EXEC('SELECT 43112609 AS val;')
WITH RESULT SETS
(
(
val VARCHAR(10)
)
);
Article here:
http://www.itprotoday.com/sql-server-2012-t-sql-glance-execute-result-sets
SQL can not tell what is being returned when using temp/table variablbes so you have to specify this. It is needed for some versions of SQL Server.
So at my company we use a billing system which connects to a Firebird database that we have no back-end access to. I am quite new at this company so my familiarity with the Firebird database is not too great. We keep getting this error :
ERROR: Database Engine Error
Sender Class: TGLPreviewBtn
Exception Class: EIBODBError.
IBO ErrorERRCODE=335544569 SQLCODE=-204
Error Message:
ISC ERROR CODE:335544569
ISC ERROR MESSAGE:
Dynamic SQL Error
SQL error code = -204
Procedure unknown
GET_SUB_CONTACTLIST
At line 3, column 60
This has been a recurring thing since I've been hired (I've been here for about 45 days), and we've reported this error to the company which hosts the billing system that we use to access the database. The company keeps saying that it's a network issue on our end, however I cannot see any indication of a connection drop on our end.
I have to reiterate that we have no back-end access to this database so I have no way of going to see what GET_SUB_CONTACTLIST even refers to.
Any help will be appreciated, I am just out of college and this is my first job in a position like this so I will use this as a great learning experience.
This cannot be a network error on your end. The error literally means that Firebird was asked to execute a stored procedure called GET_SUB_CONTACTLIST, and that stored procedure does not exist at that time.
So either someone (or something) is creating and dropping stored procedures on the fly, or part of the application is calling a stored procedure that simply does not exist.
As an aside: error 335544569 (aka isc_dsql_error) covers a broad range of error conditions with 'dynamic' SQL (in other words: most SQL related errors...), unfortunately a lot of client libraries do not communicate the more specific error code 335544581 (or isc_dsql_procedure_err).
We're using two schemas in our project (dbo + kal).
When we are trying to create a view with the following SQL statement, Visual Studio shows as an error in the error list.
CREATE VIEW [dbo].[RechenketteFuerAbkommenOderLieferantenView]
AS
SELECT
r.Id as RechenkettenId,
r.AbkommenId,
r.LieferantId,
rTerm.GueltigVon,
rTerm.GueltigBis,
rs.Bezeichnung,
rs.As400Name
FROM
[kal].[Rechenkette] r
JOIN
[kal].[RechenketteTerm] rTerm ON rTerm.RechenketteId = r.Id
JOIN
[kal].[Basisrechenkette] br ON rTerm.BasisrechenketteId = br.Id
JOIN
[kal].[Rechenkettenschema] rs ON rs.Id = br.Id
WHERE
r.RechenkettenTyp = 0
The error message looks like this:
SQL71501: Computed Column: [dbo].[RechenketteFuerAbkommenOderLieferantenView].[AbkommenId] contains an unresolved reference to an object. Either the object does not exist or the reference is ambiguous because it could refer to any of the following objects:
[kal].[Basisrechenkette].[r]::[AbkommenId], [kal].[Rechenkette].[AbkommenId], [kal].[Rechenkette].[r]::[AbkommenId], [kal].[Rechenkettenschema].[r]::[AbkommenId] or [kal].[RechenketteTerm].[r]::[AbkommenId].
Publishing the view and working is just fine, but its quite annoying to see the error message all the time when building our project having all the serious errors get lost in the shuffle of those sql errors.
Do you have any idea, what the problem might be?
I just found the solution. Although I can't read your (what appears to be German) enough to know if you're referring to system views, if so, a database reference to master must be provided. Otherwise, adding any other required database references should solve the problem.
This is described here for system views: Resolve reference to object information schema tables
and for other database references.
Additional information is provided here: Resolving ambiguous references in SSDT project for SQL Server
For me I was seeing SQL71501 on a user defined table type. It turned out that the table type's sql file in my solution wasn't set as build. As soon as I changed the build action from None to Build, the error dissapeared.
I know this is an old question but it was the first one that popped up when searching for the error.
In my case the errors were preventing me from executing the SqlSchemaCompare in Visual Studio 2017. The error however was for a table/index of a table that was not part of the solution any more. A simple clean/rebuild did not help.
A reload of the visual studio solution did the trick.
We have a project that contains a view that references a table valued function in another database. After adding the database reference that is required to resolve the fields used from the remote database, we were still getting this error. I found that the table valued function was defined by using "SELECT * FROM ..." which was old code created by someone not familiar with good coding practices. I replaced the "*" portion with the enumerated fields needed and compiled that function, then re-created the dacpac for that database to capture the resulting schema, and incorporated the new dacpac as the database reference. Woo Hoo! the ambiguous references went away! Seems that SSDT engine cannot (or does not) always have the ability to reach down into the bowels of the referenced dacpac to come back with all the fields. For sure, the projects I work on are normally quite large, so I think it makes sense to give the tools all the help you can when asking them to validate your code.
Although this is an old topic, it is highly ranked on search engines, so I will share the solution that worked for me.
I faced the same error code with a CREATE TYPE statement, which was in a script file in my Visual Studio 2017 SQL Server project, because I couldn't find how to add a user-defined type specifically from the interface.
The solution is that, in Visual Studio, there are many programmability file types, other than the ones you can see through a right-click > Add. Just select New Element and use the search field to find the element you are trying to create.
From the last paragraph of the blog post Resolving ambiguous references in SSDT project for SQL Server, which was linked in the answer https://stackoverflow.com/a/33225020/15405769 :
In my case, when I double clicked the file and opened it I found that
one of the references to ColumnX was not using the two part name and
thus SSDT was unable to determine which table it belonged to and
furthermore whether the column existed in the table. Once I added the
two part name. Bingo! I was down to no errors!
In my case, I got this error when I was trying to export the datatier application. The error was related to the link on a database user. To solve the problem, you need to log in to the server with read rights on system users.
In my case I just double click on the error and it will take me to the exact error on procedure and I noticed that table column is deleted or renamed but in SP its still using the old column name.
If you build an SSDT project you can get an error which says:
“SQL71502: Function: [XXX].[XXX] has an unresolved reference to object [XXX].[XXX].”
If the code that is failing is trying to use something in the “sys” schema or the “INFORMATION_SCHEMA” schema then you need to add a database reference to the master dacpac:
Add a database reference to master:
Under the project, right-click References.
Select Add database reference….
Select System database.
Ensure master is selected.
Press OK.
Note that it might take a while for VS to update.
(Note this was copied verbatim from the stack overflow question with my screenshots added: https://stackoverflow.com/questions/18096029/unresolved-reference-to-obj… - I will explain more if you get past the tldr but it is quite exciting! )
NOT TLDR:
I like this question on stack overflow as it has a common issue that anyone who has a database project that they import into SSDT has faced. It might not affect everyone, but a high percentage of databases will have some piece of code that references something that doesn't exist.
The question has a few little gems in it that I would like to explore in a little more detail because I don't feel that a comment on stack overflow really does them justice.
If we look at the question it starts like this:
If you're doing this from within Visual Studio, make sure that the file is set to "Build" within the properties.
I've had this numerous times and it really gets me everytime. SQL Build is case sensitive even though your collation isn't. Check the case is correct in agreement with the object and schema names that are referenced!
We have a scalar function in the database that calls an assembly using sp_OA methods. The scalar function is called from a view. The SQL Server is Microsoft 2008 R2, a 32-bit installation. We have the same database installed on three different servers. On one of them the call to function fails with this message
Msg 557, Level 16, State 2, Line 2 Only functions and some extended
stored procedures can be executed from within a function.
On the other two it works fine. Is there a setting we are missing on that one specific SQL Server? Or can it be something else? The internet is ambiguous about this error.
Thank you.
Thank you for the tips. The problem resolved itself rather unglamorously. It seems that an unhandled error in legacy code, through faulty data, was throwing the scalar function into a fit, causing the that particular error to show up.
Thank you.
I've hit a bit of an impasse. I have a query that is generated by some C# code. The query works fine in Microsoft SQL Server Management Studio when run against the same database.
However when my code tries to run the same query I get the same error about an invalid column and an exception is thrown. All queries that reference this column are failing.
The column in question was recently added to the database. It is a date column called Incident_Begin_Time_ts .
An example that fails is:
select * from PerfDiag
where Incident_Begin_Time_ts > '2010-01-01 00:00:00';
Other queries like Select MAX(Incident_Being_Time_ts); also fail when run in code because it thinks the column is missing.
Any ideas?
Just press Ctrl + Shift + R and see...
In SQL Server Management Studio, Ctrl+Shift+R refreshes the local cache.
I suspect that you have two tables with the same name. One is owned by the schema 'dbo' (dbo.PerfDiag), and the other is owned by the default schema of the account used to connect to SQL Server (something like userid.PerfDiag).
When you have an unqualified reference to a schema object (such as a table) — one not qualified by schema name — the object reference must be resolved. Name resolution occurs by searching in the following sequence for an object of the appropriate type (table) with the specified name. The name resolves to the first match:
Under the default schema of the user.
Under the schema 'dbo'.
The unqualified reference is bound to the first match in the above sequence.
As a general recommended practice, one should always qualify references to schema objects, for performance reasons:
An unqualified reference may invalidate a cached execution plan for the stored procedure or query, since the schema to which the reference was bound may change depending on the credentials executing the stored procedure or query. This results in recompilation of the query/stored procedure, a performance hit. Recompilations cause compile locks to be taken out, blocking others from accessing the needed resource(s).
Name resolution slows down query execution as two probes must be made to resolve to the likely version of the object (that owned by 'dbo'). This is the usual case. The only time a single probe will resolve the name is if the current user owns an object of the specified name and type.
[Edited to further note]
The other possibilities are (in no particular order):
You aren't connected to the database you think you are.
You aren't connected to the SQL Server instance you think you are.
Double check your connect strings and ensure that they explicitly specify the SQL Server instance name and the database name.
In my case I restart Microsoft SQL Sever Management Studio and this works well for me.
If you are running this inside a transaction and a SQL statement before this drops/alters the table you can also get this message.
I eventually shut-down and restarted Microsoft SQL Server Management Studio; and that fixed it for me. But at other times, just starting a new query window was enough.
If you are using variables with the same name as your column, it could be that you forgot the '#' variable marker. In an INSERT statement it will be detected as a column.
Just had the exact same problem. I renamed some aliased columns in a temporary table which is further used by another part of the same code. For some reason, this was not captured by SQL Server Management Studio and it complained about invalid column names.
What I simply did is create a new query, copy paste the SQL code from the old query to this new query and run it again. This seemed to refresh the environment correctly.
In my case I was trying to get the value from wrong ResultSet when querying multiple SQL statements.
In my case it seems the problem was a weird caching problem. The solutions above didn't work.
If your code was working fine and you added a column to one of your tables and it gives the 'invalid column name' error, and the solutions above doesn't work, try this: First run only the section of code for creating that modified table and then run the whole code.
Including this answer because this was the top result for "invalid column name sql" on google and I didn't see this answer here. In my case, I was getting Invalid Column Name, Id1 because I had used the wrong id in my .HasForeignKey statement in my Entity Framework C# code. Once I changed it to match the .HasOne() object's id, the error was gone.
I've gotten this error when running a scalar function using a table value, but the Select statement in my scalar function RETURN clause was missing the "FROM table" portion. :facepalms:
Also happens when you forget to change the ConnectionString and ask a table that has no idea about the changes you're making locally.
I had this problem with a View, but the exact same SQL code worked perfectly as a query. In fact SSMS actually threw up a couple of other problems with the View, that it did not have with the query. I tried refreshing, closing the connection to the server and going back in, and renaming columns - nothing worked. Instead I created the query as a stored procedure, and connected Excel to that rather than the View, and this solved the problem.