How to report Errors or bugs found in SQL Server to Microsoft SQL Server Team ?
The error message is correct.
You have two operands.
The literal 'a' is treated as varchar(1) and the second one is varbinary(30) (30 is the default if no length is specified in a CAST). It is invalid to concatenate these mixed datatypes.
[var]char + [var]char works fine
[var]binary + [var]binary is also fine
To answer your question though bug reports should go on the Connect site but always worth sanity checking that it is a genuine bug first!
Related
I'm a finance person (little programming background) so I maybe asking something obvious for database programming experts but will appreciate any advice
Background:
I'm accessing Oracle NetSuite database via ODBC from Microsoft SQL Management Studio
Connection as a Linked Server is established successfully
I'm trying to execute the following SQL statements:
select * from [NETSUITE_SB2].[SB-B].[Administrator].[VARIANCE] -- success
select * from [NETSUITE_SB2].[SB-B].[Administrator].[WTAX_JOB] -- "Msg 7314, Level 16, State 1, Line 1
The OLE DB provider "MSDASQL" for linked server "NETSUITE_SB2" does not contain the table ""SB-B"."Administrator"."WTAX_JOB"". The table either does not exist or the current user does not have permissions on that table."
Upon some testing, it appears that whether the query is successfully run depends on whether the table name contains "_" (underscore) - for all tables without underscore I've tried, it worked, for all tables with underscore that I've tried, it failed.
Can anyone help me figure out how to overcome this?
Thanks in advance!
Instead of using a 4-part name in SQL Server and having SQL Server generate a query for the linked server, try using the OPENQUERY function and passing a query in the target system's SQL dialect directly. Something like:
select *
from OPENQUERY([NETSUITE_SB2], 'select * from [SB-B].[Administrator].[WTAX_JOB]' )
I just encountered this myself in a new instance that I just set up. I had been using Suite Connect for 4+ years without running into this issue before.
I believe the issue with the situation here is the "[SB-B]" part of the name because it contains the "-" dash. I found that a "," comma or "." period were the issue with my name [Acme, Inc.]. Ether the period or comma threw the error.
The second part of the 4-part name is the NetSuite [Company Name] under General Settings Company Info. I changed the name in NetSuite and removed the comma and period and the problem went away. Maybe most special characters cause the issue?
Just remember you'll have to update your second part name in each query you created before.
While using OPENQUERY is a solution, I just don't like the extra quotes needed so I prefer normal SQL.
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
Unfortunately we are using the Advantage Database Server Torture Edition Version 8.1.
After I had finished my project, I heard that the data base is configured to be case sensitive. So I changed the table structure, all Char data types to CIChar, which is a case insensitive char field. But I get this error while executing my program:
Advantage.Data.Provider.AdsException:
Error 7200: AQE Error: State =
HY000; NativeError = 2214;
[Extended Systems][Advantage SQL
Engine]Invalid coercion: Result of
expression is an ambiguous character
type.
I found that the ISNULL(myciChar,'') is causing this problem, but I don't understand, WHY?
How could I solve this problem? Is there other known issues with the cichar data type?
Any help will be appreciated. Thanks.
[update]
I found the reason for this error. There was two points to clarify.
The data base has the version 8.1, but the data architect has the version 7.1 and in local mode it takes the architect engine version 7.1. That means it's a v7.1 issue.
The 2nd parameter in the isnull function is in default case sensitive collation in version 7.1 while my column mytext is cichar and that's the ambiguous character type. So if someone has the same problem, it will work in v7.1 with the collate declaration:
works in v7.1:
select myid, isnull(mytext, '-' COLLATE ads_default_ci) as mytext from mytable
error in v7.1:
select myid, isnull(mytext, '-') as mytext from mytable
Probably need to see more of your expression to tell you why you are getting this error. It doesn't have as much to do with the ISNULL as it does the expression the ISNULL is being used in. The engine likely encountered a comparison and couldn't automatically determine if you wanted the comparison to be case sensitive or not. See the documentation which describes case insensitive precedence and coercion.
If not used in an expression, it might just be a bug (I just tried with 10.1 and it worked), verify you are using the latest version of 8.1, which is 8.10.0.38
I don't think that version 7 supports the cichar data type, version 6 certainly doesn't. I was using version 6 and went straight to 8 and found that everything worked with the version 6 client driver, until I used the cichar data type and then it was game-over for Advantage. I then had to update all the clients to the same version as the server. It is best to keep all the versions the same.
I get [Informix][Informix ODBC Driver][Informix]A syntax error has occurred when running the query below. When I remove the double apostrophes the query executes successfully. Everything I can find by Googling tells me I'm doing the right thing. Seven years ago I used Informix without this sort of problem so I think I've forgotten something important!
insert into ct_repairs (ct_job_no,inh_job_no,reference,tab
,rec_date,rec_time,priority,start_dte,start_tme,app_date
,app_time,card_date,card_time,est_date_comp,est_time_comp
,act_date_comp,act_time_comp,exp_code,ct_notes,ct_status
) values (
2090
,335706
,'23026002003'
,'P'
,NULL
,''
,1
,"22/02/2010"
,'10:47'
,NULL
,''
,"22/02/2010"
,'11:14'
,NULL
,''
,NULL
,''
,'DTD'
,'**PLS NOTE PLANNED WRKS GOING ON ON ASCOT RD,IE ROOFS,RENDERERING,AND HIGH LEVEL CLOSE BOARD FENCES:SPOKE TO THE LADY AT NO 2 SHE DOESN''T NO ANYTHING ABOUT FENCE ISSUES,CALLED AT NO 4#6 ASCOT NO ACCESS TO EITHER PROPERTIES**:YOU YOU PLS SEND A EMAIL TO TREVOR ON PLANNED ASKING IF NO 2 ASCOT RD IS DOWN FOR A NEW CLOSED BOARDED FENCE,OR IS THAT THE PROBLEM NO 4 BEING PRIVATE THAT THEY HAVEN''T PUT ONE UP**'
,0
)
It would be helpful if you identified the version of ODBC you are using, and the version of IDS (IBM Informix Dynamic Server), and the platform where they are running.
When I copy'n'paste the code from the question into SQLCMD (equivalent to DB-Access) in a database without the table, I get the error:
SQL -206: The specified table (ct_repairs) is not in the database.
This indicates that the SQL is syntactically correct.
So, why are you seeing an error?
My first suspect for the guilty party is the long (400+) character string at the end. At one time (a while ago now, AFAICR) there was an upper bound of 255 on the length of a character string literal. If you are using an old enough version of the ODBC driver (or IDS), this could be a factor.
My second suspect is the occasional double-quoted date string. Informix is generally lax about whether you use single or double quotes around strings; this can be helpful. However, there is a way to make it pedantic like the SQL standard, requiring single quotes around strings and using double quotes only for 'delimited identifiers'. If the DELIMIDENT environment variable is set (perhaps via SETNET32 on Windows), the strict mode would be invoked, and when I do that in SQLCMD, I get:
SQL -201: A syntax error has occurred.
The third suspect is that the long column is a BYTE or TEXT (or possibly BLOB or CLOB) type, and there isn't a conversion from a string literal to that type. However, AFAIK, the ODBC driver jumps through hoops to deal with that problem, and the error would be different, probably something like:
SQL -617: A blob data type must be supplied within this context.
So, at the moment, I think the DELIMIDENT is well worth chasing - it is probably easily fixed (either by ensuring that dates are enclosed in single quotes or by unsetting DELIMIDENT). Failing that, try a shorter string and see whether that works.
But your basic understanding is correct - you are using doubled-up single quotes correctly.
I'm working on a legacy product and i have some SQL being executed through ADO, to an Access database with linked tables to SQL Server. I'm getting the error 'Undefined function 'Round' when i execute the SQL but if i take the query and run directly in Access it works fine. I know that EVERYTHING is correct and that this is a machine specific issue since this is production code, it works on other machines and has been deployed successfully for many clients.
I'm not even sure where to begin to be honest. I'm running the correct (latest) versions of Jet/ADO/MDAC.
ANY help would be appreciated.
Thanks in advance.
EDIT: Obviously, the SQL includes the aggregate function 'Round'. I'm aware of the differences between Jet and SQL implementations. This problem is due to some problem with a component on my machine and NOT with the code. The SQL executes properly when done through MS Access 2007 but NOT through ADO.
EDIT2: Right solution from the comments:
shahkalpesh: If it executes fine thru Access, it could be that Access has the DLL available to it, which has the Round function. What is the connection string, you are using?
Stimul8d: I'm not sure how it can be anything so do with the connection string. This code works on EVERY other machine, with no changes; just not on mine.
Andomar: Well, that's your problem right there, your machine is farked up. You can still install vb6 sp6 maybe.
Stimul8d: Well, SP6 fixed it. Cheers Anndomar, no idea why SP6 fixed it but it did!
EDIT: Based on your comment this newsgroup post might be the answer:
Unfortunately, when you are running
queries from outside of Access (as you
are from VB), your only connection to
the database is through the Jet
engine, which doesn't know anything
about most VBA functions. There's no
way around this, other than to return
the data to your VB application and
use the functions on the data there.
And two posts later:
I solved the problem. Updated my VB
with the Service Pack 6... it took
care of the problems.
Old answer here:
Try FLOOR() instead of ROUND().
To round something to the nearest integer, you could:
declare #floatmyboat float
set #floatmyboat = 1.51
select floor(#floatmyboat+0.5)
P.S. Maybe post the exact error you get. If it's "The round function requires 2 to 3 arguments.", that means Sql Server is borking on the ROUND().
The round() function exists in SQL Server as well.
The only difference is: in Access the precision is an optional parameter, but in SQL Server you have to specify it.
So this will only work in Access, but not in SQL Server:
select round(Column) from Table
This will work in Access and SQL Server:
select round(Column,1) from Table
it could be that Access has the DLL
available to it, which has the Round
function
ACE/Jet uses share expression services with VBA. Broadly speaking, ACE/Jet supports as expressions all VBA5 functions (as distinct from methods) whose arguments and return values are scalar types (e.g. no arrays, no objects). The Round() expression falls into this definition and indeed is available to ACE/Jet with the same semantics as its VBA function equivalent. As anyone familiar with the ACE/Jet engine should know, though, the semantics can differ from the VBA equivalents e.g. ACE/Jet ANSI-92 Query Mode SQL
SELECT TYPENAME(ROUND(5, 1))
returns 'Long', whereas VBA
?Typename(Round(5, 1))
returns 'Integer'.
In other words, Round() wasn't going to be the problem here.