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.
I want to upgrade my web server to newest Ubuntu version and hence also upgrade php5 to php7. I completed the installation and configuration of a VM running lubuntu 16.04 to test things, to see if code changes are needed and also test if it works in general.
In the first application I face a strange issue with oracle (oci8). The application uses server-side paging and also displays stuff like "Total Records" and "Total records (filtered)". Of course these "metrics" are based on simple count queries and they work and display the correct result. However the select statement to get the actually data returns 0 hits. Especially puzzling because it uses the exact same query:
$sQueryInner = "SELECT id, ROW_NUMBER() OVER ($sOrderByClause) R
FROM my_table " . $sWhereClause;
$sQueryFinal = "SELECT id FROM
(" . $sQueryInner . ")
WHERE R BETWEEN :startIndex and :endIndex";
// Total data set length after applying where
$sQueryFilteredCount = "SELECT COUNT(*) as \"totalRowsCount\" FROM (" . $sQueryInner . ")";
Only difference is the ROW_NUMBER() clause but I don't see how that affects things that no results are returned. I also get no error messages or php warnings. oci_fetch_array immediately returns false meaning no further rows found.
while ($row = oci_fetch_array($statementFinal, OCI_ASSOC + OCI_RETURN_NULLS)) {//...
I wanted to find a way to debug oci8 itself. To see the actual SQL sent. But oci_internal_debug seems to be disabled since php5.6.
So I'm pretty lost. Any ideas what could cause this and how I could further debug/search for why it is caused?
EDIT:
Wit wireshark I can actually see the SQL sent to the DB and it's correct. Problem is no rows are returned. Only conclusion is that parameter binding doesn't work properly and hence no results are returned. I don't get it however as the exact same thing works on ubuntu 14.04. Only difference is php7. All other applications also work so the issue is with this specific query. It has a subselect and Row_number() function.
This is another WTF of php. Def. considering rewrite in other language...Seriously php guys, get a grip...
They changed something fundamental which impacts oci_bind_by_name but don't mentioned it anywhere.
The issue can be fixed by reordering your code. Meaning you have to do it in this order if you bind your statements in a function call:
Create Statements
Bind Statement 1
execute statement 1
Bind Statement 2
execute statement 2
and so forth. If you first bind all statements and then execute it, a later call to bind will overwrite previous value even if the parameter has a completely different name and type. WTF?
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!
Earlier we were using Sybase as the back end. Now we are migrating to SQL server where as front end remains the same i.e. PowerBuilder.
Issue :
I have a DataWindow code which takes two retrieval arguments adt_from_date and adt_to_date. Both Date format. This works fine for PB-Sybase combination, but throws an error 37000 for SQL server.
Here is our code. If I hard-code the dates. i.e. for e.g. if I replace :adt_from_date by '20141001'. The code works fine.
SELECT A.MEMBER_NO AS 'MEMBER_NO',
ROUND(SUM(TRANSACTION_CHARGES),2) as 'AMOUNT',
SUBSTRING(DATENAME(MM, :adt_from_date ),1,3) +'-'+substring(convert(varchar,datepart(YY, :adt_from_date )),3,2) as 'REASON'
FROM TRAN_SERVICE_TAX_DRV A,
MEMBER_MASTER B
WHERE A.MEMBER_NO = B.MEMBER_NO
AND A.TRADE_DATE BETWEEN :adt_from_date AND :adt_to_date
GROUP BY A.MEMBER_NO
Please suggest something on this.
I'd suggest you look at the error text being loaded into the transaction instead of just the number; it will probably be much more helpful. If we're talking about SQLState 37000, that doesn't narrow it down much.
If that doesn't shed some light on it, I'd look at tracing either on the PowerBuilder side, or on the database side. Starting on the PB side probably makes most sense. If you're just running this DataWindow from the IDE, the trace is just a checkbox on the connection properties. If in the app, replace your "DBMS='xxx'" with "DBMS='tra xxx'" (there are other options described in the Connecting to your Database manuals).
Good luck.
Issue with Delphi legacy code. Added one line of code to correct one error and created a new error.
New error is causing the same executable to yield different results on different servers(switched the pointer from dev to prod environment on the executable).
code:
sEscapedString:=stringreplace(sStringIn,'[','''+char(27)+''[',[rfReplaceAll]);
sEscapedString:=stringreplace(sEscapedString,']','''+char(27)+'']',[rfReplaceAll]);
sEscapedString:=stringreplace(sEscapedString,'''','''''',[rfReplaceAll]);// this line created new
bug
result:=' like ''' + Trim(sEscapedString) + '%'''+' escape char(27) ';
When running the code against dev this query finds objects with the characters '[' and ']' in it
Against prod the query does not find those items:
The first thing I checked was the data: Exactly identical in both cases
The second thing I checked was SQL server versions (11.0.3128 on BOTH servers)
The third thing I am checking is settings on those servers:
DBCC USEROPTIONS; -- same on both
SELECT name, collation_Name FROM sys.databases -- same on both
select ##OPTIONS -- same on both.
Quoted identifiers are 'ON' for both servers
It comes down to the fact that I know one server is treating the escape character (chr(27)) differently than the other but I do knot know why.
Does anyone have a theory(or answer) as to why the 2 similar servers are treating the escape characters differently?
The goal here is getting the prod server to return values with '[' and ']', as setting up my system to work with the legacy code will take a LOT of additional time. I do have a fix for the code
sEscapedString:=stringreplace(sStringIn,'[','[[]',[rfReplaceAll]);
But the faster option would seem to be getting the server to read the values the same.
Update: We found the root cause of the difference and it was more mundane than what we expected, turns out the query we were running was actually executed twice. The second execution was missing the key piece on the production server.
The issue was resolved by moving the new line of code so that it executed first rather than last.
I would first try to find out if this SQL only causes different behaviour when it is sent from the application: by sending the SQL from an interactive SQL client tool to both servers.
To make sure that the manually tested SQL is exactly the same as in the application, I would try to log or capture the exact SQL as sent from the application as a text file and then paste its content to the SQL client tool.
If the server is the culprit, then using the SQL from a different client tool should cause the same difference with the two servers. If the client tool shows the same (correct) result on both servers, then something is going on in the Delphi application.
p.s. upvoted, it is an interesting phenomenon