Query works in SQL Server but not in R - sql

I wrote a query in SQL Server and it ran without a problem. Here's the query with the names changed for privacy reasons.
SELECT *
FROM table1 (nolock)
LEFT JOIN table2 (nolock)
ON table1.ID = table2.ID
WHERE table1.Date = '2021-03-05' AND table1.ID = '120';
This works fine and pulls 30k rows. I have created an ODBC connection using the DBI and odbc packages to the server in R. I can run queries from R just fine. I've run many without an issue. For example, this runs with no errors:
DBI::dbGetQuery(conn, believeNRows = FALSE, "
SELECT TOP 10 *
FROM table1 (nolock);
")
But when I include a LEFT JOIN, then the query in R fails and returns an error.
Here's the same query in R:
DBI::dbGetQuery(conn, believeNRows = FALSE, "
SELECT *
FROM table1 (nolock)
LEFT JOIN table2 (nolock)
ON table1.ID = table2.ID
WHERE table1.Date = '2021-03-05' AND table1.ID = '120';
")
I'm working in VSCode so the error message isn't very informative:
Error in app$vspace(new_style$margin-top %||% 0) : attempt to
apply non-function
Based on some other answers, I included a couple of extra options in the query, but they didn't help:
DBI::dbGetQuery(conn, believeNRows = FALSE, "
SET ANSI_WARNINGS OFF;
SET NOCOUNT ON;
SELECT *
FROM table1 (nolock)
LEFT JOIN table2 (nolock)
ON table1.ID = table2.ID
WHERE table1.Date = '2021-03-05' AND table1.ID = '120';
")
Does anyone have any idea why this perfectly good query isn't working when passed to SQL Server from within R?

In case any one else has this problem in the future, there were two hurdles in my way. First, relative to #r2evans comment, my error messages were being masked. Per a readr github issue, I reinstalled the cli package and started getting unmasked error messages. Reran my code and received this error:
Error:
! Column names `ID1` and `Col1` must not be duplicated.
Use .name_repair to specify repair.
Caused by error in `stop_vctrs()`:
! Names must be unique.
x These names are duplicated:
* "ID1" at locations 3 and 72.
* "Col1" at locations 45 and 75.
Run `rlang::last_error()` to see where the error occurred.
Turns out, the SQL call brings back all columns and SSMS removes the duplicate columns automatically. R, on the other hand, does not. So I changed my SELECT clause to choose the specific columns I wanted and the code worked.

Related

Accessing multiple tables in SQLEXEC statement, SQL Pass Through

I create a cursor called 'table1_data' from the statement:
lnResult1 = SQLEXEC(m.hConn, 'select * from table1 where status like ?m.seeStatus','table1_data')
Now I want to access this table in my next SQLEXEC statement:
lnResult2 = SQLEXEC(m.hConn, 'select * from table2 where table2.item_id = table1_data.item_id','table2_data')
however I get the error: The multi-part identifier table1_data.item_id could not be bound. Any help much appreciated!
In first case table1_data is a local cursor and you cannot use it in second call which is made to server.
However since table1_data is also coming from server side you could instead do this:
*** Using text ... endtext just to make the SQL more readable
local lcSQL
text to m.lcSQL noshow
select * from table2
where exists (select * from table1
where table2.item_id = table1_data.item_id and
table1.status like ?m.seeStatus);
endtext
lnResult1 = SQLEXEC(m.hConn, 'select * from table1 where status like ?m.seeStatus','table1_data')
lnResult2 = SQLEXEC(m.hConn, m.lcSQL,'table2_data')
EDIT: BTW you can return 2 results from a single SQLExec() call however it is not worth it here in this case. Two separate queries as above is just fine (and remember you could make them updatable per table).
You can join both tables, but instead of SELECT * you should always neme the columns that you only need.
that helps also in future.
lnResult1_2 = SQLEXEC(m.hConn, 'select table1.*,table2.* from table1, table2 where table2.item_id = table1_data.item_id AND status like ?m.seeStatus')
I can't find any code related to joins, but
lnResult1_2 = SQLEXEC(m.hConn, 'select table1.*,table2.* from table1 JOIN table2 ON table2.item_id = table1_data.item_id WHERE status like ?m.seeStatus')
should also work, but as i said i can't find any code that uses explicit join, so you can give it a try and give a short response

Why does Oracle SQL update query return "invalid identifier" on existing column?

I have an update query for an Oracle SQL db. Upon execution the query returns ORA-00904: "t1"."sv_id": invalid identifier
So, why do I get an "invalid identifier" error message although the column exists?
Here is the complete query (replaced actual table and column names by dummies in np++)
UPDATE table_1 t1 SET (type) =
CASE
WHEN
((SELECT COUNT(dateCheck.id) FROM table_2 dateCheck
WHERE dateCheck.s_id = t1.s_id AND dateCheck.sv_id = t1.sv_id) = 0)
THEN
(SELECT sv.type FROM table_3 sv WHERE sv.id = t1.sv_id)
ELSE
(SELECT type FROM
(SELECT d.type as type FROM table_2 d
WHERE d.s_id = t1.s_id AND d.sv_id = t1.sv_id
ORDER BY d.creationTimestamp ASC)
WHERE ROWNUM = 1)
END
Now I don't understand why that error occurs.
Here is what I already know:
The Queries in the CASE statement work when executed separately, provided they are wrapped into a query that provides table_1 t1 for sure.
t1.s_id seems to work since oracle doesn't complain about that. When i change it to a column that really doesn't exist, oracle starts complaining about that non existent column before returning something about t1.sv_id. So somehow the alias might work, although I'm not sure about it.
I'm 100% sure that the column t1.sv_id exists and no typo was made. Executed a query on t1 directly and doublechecked everything in notepad by marking all occurences.
An (completely unrelated) update query like the following works as well (note the alias t1 is used in the select query). Don't assume table_1/2 to be the same as in the update query above, just reused the names. This should just illustrate that I successfully used an alias in an update query before.
update table_1 t1 set (t2_id) = (select id from table_2 t2 where t1.id = t2.t1_id)
UPDATE
Thx a lot for pointing me to the "you don't have access to alises in deeper suquery layers" issue. That got me on track again pretty fast.
So here is the query I ended up with. This seems to work fine. Eliminates the acces to t1 in the deeper layers and selects the oldest row, so that the same result should be returned from the query I expected from the original query in the ELSE part.
UPDATE table_1 t1 SET (type) =
CASE
WHEN
((SELECT COUNT(dateCheck.id) FROM table_2 dateCheck
WHERE dateCheck.s_id = t1.s_id AND dateCheck.sv_id = t1.sv_id) = 0)
THEN
(SELECT sv.type FROM table_3 sv WHERE sv.id = t1.sv_id)
ELSE
(SELECT d.type as type FROM table_2 d
WHERE d.s_id = t1.s_id
AND d.sv_id = t1.sv_id
AND d.creation = (SELECT MIN(id.creation) FROM table_2 id
WHERE d.s_id = id.s_id AND d.sv_id = id.sv_id))
END
You can't reference a table alias in a subquery of a subquery; the alias doesn't apply (or doesn't exist, or isn't in scope, depending on how you prefer to look at it). With the code you posted the error is reported against line 11 character 24, which is:
(SELECT type FROM
(SELECT d.type as type FROM table_2 d
WHERE d.s_id = t1.s_id AND d.sv_id = t1.sv_id
^^^^^^^^
If you change the t1.s_id reference on the same line to something invalid then the error doesn't change and is still reported as ORA-00904: "T1"."SV_ID": invalid identifier. But if you change the same reference on line 5 instead to something like
((SELECT COUNT(dateCheck.id) FROM table_2 dateCheck
WHERE dateCheck.s_id = t1.s_idXXX AND dateCheck.sv_id = t1.sv_id) = 0)
... then the error changes to ORA-00904: "T1"."S_IDXXX": invalid identifier. This is down to how the statement is being parsed. In your original version the subquery in the WHEN clause is value, and you only break it by changing that identifier. The subquery in the ELSE is also OK. But the nested subquery in the ELSE has the problem, and changing the t1.s_id in that doesn't make any difference because the parser reads that part of the statement backwards (I don't know, or can't remember, why!).
So you have to eliminate the nested subquery. A general approach would be to make the whole CASE an inline view which you can then join using s_id and sv_id, but that's complicated as there may be no matching table_2 record (based on your count); and there may be no s_id value to match against as that isn't being checked in table_3.
It isn't clear if there will always be a table_3 record even then there is a table_2 record, or if they're mutually exclusive. If I've understood what the CASE is doing then I think you can use an outer join between those two tables and compare the combined data with the row you're updating, but because of that ambiguity it needs to be a full outer join. I think.
Here's a stab at using that construct with a MERGE instead of an update.
MERGE INTO table_1 t1
USING (
SELECT t2.s_id,
coalesce(t2.sv_id, t3.id) as sv_id,
coalesce(t2.type, t3.type) as type,
row_number() over (partition by t2.s_id, t2.sv_id
order by t2.creationtimestamp) as rn
FROM table_2 t2
FULL OUTER JOIN table_3 t3
ON t3.id = t2.sv_id
) tmp
ON ((tmp.s_id is null OR tmp.s_id = t1.s_id) AND tmp.sv_id = t1.sv_id AND tmp.rn = 1)
WHEN MATCHED THEN UPDATE SET t1.type = tmp.type;
If there will always be a table_3 record then you could use that as the driver and have a left outer join to table_2 instead, but hard to tell which might be appropriate. So this is really just a starting point.
SQL Fiddle with some made-up data that I believe would have hit both branches of your case. More realistic data would expose the flaws and misunderstandings, and suggest a more robust (or just more correct) approach...
Your query and your analysis seems sound to me. I have no solution but a few things you can try to maybe trigger something that explains this odd behavior:
Quote the column (just in case it happens to be a SQL keyword).
Use table_1.sv_id - this works as long as the whole query contains this table only once.
Make sure that the alias t1 exists only once
Run the query with a query tool like SQuirrel SQL - the tool can examine the exact position where Oracle reports the problem. Maybe it's in a different place of the query than you think
Check () and make sure they are around the parts where they should be.
Swap the order of expressions around =

SQL Left Outer Join causes Msg 4145 (non-boolean where boolean expected)

I'm new here so if I do something that breaks convention please let me know.
I am trying to create a simple query that includes a single outer join before I move onto a larger and more complicated query. When I run my query before adding the join it works as expected. When I add the join the query returns an error message. I cannot determine the cause of the error. I am working in Microsoft SQL Server 2008 R2.
This query runs successfully and produces the expected results:
use MyDatabase
select table1.ID_NUM,
table1.LAST_NAME
From table1,
table2
where table1.id_num = table2.id_num
This query does not run successfully:
use MyDatabase
select table1.ID_NUM,
table1.LAST_NAME
From table1,
table2
where table1 left outer join table2 on table1.id_num = table2.id_num
The error message I get is:
Msg 4145, Level 15, State 1, Line 6
An expression of non-boolean type specified in a context where a condition is expected, near 'left'.
I also tried "outer join" instead of "left outer join", but this produced a similar error message (the only difference was "near 'outer'" instead of "near 'left'").
I do know what boolean means but I am not sure why it's an issue here. The boolean operator comes later in the same line. My code looks like it follows the same format as other code I have seen. Any assistance would be appreciated.
your join needs to be after the FROM not in the WHERE clause
use MyDatabase
select table1.ID_NUM,
table1.LAST_NAME
From table1
left outer join table2 on table1.id_num = table2.id_num
You are using deprecated syntax, listing out tables and defining their relationship in the WHERE clause has been replaced by explicit JOIN statements
FROM Table1 t1
JOIN Table2 t2
ON t1.col1 = t2.col1
LEFT JOIN Table3 t3
ON t1.col2 = t3.col1
Old style joins do allow for outer joins:
use MyDatabase
select table1.ID_NUM,
table1.LAST_NAME
From table1,table2
where table1.id_num *= table2.id_num
This old syntax should be avoided, but helpful to know what they are if you come across them.

Strange UPDATE syntax in MS Access 2003

I've got an Access application with an update query with the following syntax:
UPDATE TABLE1, TABLE2 SET
TABLE2.VALUE1 = TABLE1.VALUE1,
TABLE2.VALUE2 = TABLE1.VALUE2,
TABLE2.VALUE3 = TABLE1.VALUE3,
TABLE2.VALUE4 = TABLE1.VALUE4
The query is working but I do not understand what's going on here.
I'm trying to convert this query to SQL Server.
Can somebody please explain what this query does? My guess is that it's a special Access syntax.
Thanks,
Sven
It uses the older implicit JOIN syntax, although SQL Server should understand that syntax too.
It's INNER JOINing table1 and table2, then moving the values from table1 to table2. Because of the lack of JOIN conditions, if table1 has more than 1 row it may have unpredictable results.
Essentially it is:
UPDATE Table1 INNER JOIN Table2 <<ON Missing Conditions Here>>
SET Table2.Value1 = Table1.Value1
Table2.Value2 = Table1.Value2
Table2.Value3 = Table1.Value3
Table2.Value4 = Table1.Value4
You can convert this to SQL Server with something like this:
UPDATE Table2
SET Table2.Value1 = Table1.Value1
Table2.Value2 = Table1.Value2
Table2.Value3 = Table1.Value3
Table2.Value4 = Table1.Value4
FROM Table1 INNER JOIN Table2 <<ON Missing Conditions Here>>
Every field from TABLE2 will override corresponded field from TABLE1 with records from TABLE1 one by one. Result will be TABLE2 with all replaced records by last row from TABLE1. If TABLE1 has no records - no changes happens.
Sorry for my english.
And... it is SQL.
Try to avoid the "UPDATE with join" syntax in SQL Server. It is completely non-standard SQL but more seriously it gives unpredictable results without any error or warning if the joining criteria is not correct. Use the MERGE statement instead or use the standard version of the UPDATE statement (with a subquery) if you can.

What is a 'multi-part identifier' and why can't it be bound?

I continually get these errors when I try to update tables based on another table. I end up rewriting the query, change the order of joins, change some groupings and then it eventually works, but I just don't quite get it.
What is a 'multi-part identifier'?
When is a 'multi-part identifier' not able to be bound?
What is it being bound to anyway?
In what cases will this error occur?
What are the best ways to prevent it?
The specific error from SQL Server 2005 is:
The multi-part identifier "..." could not be bound.
Here is an example:
SELECT * FROM [MainDB].[dbo].[Company]
WHERE [MainDB].[dbo].[Company].[CompanyName] = 'StackOverflow'
The actual error:
Msg 4104, Level 16, State 1, Line 2 The multi-part identifier
"MainDB.dbo.Company.CompanyName" could not be bound.
A multipart identifier is any description of a field or table that contains multiple parts - for instance MyTable.SomeRow - if it can't be bound that means there's something wrong with it - either you've got a simple typo, or a confusion between table and column. It can also be caused by using reserved words in your table or field names and not surrounding them with [].
It can also be caused by not including all of the required columns in the target table.
Something like redgate sql prompt is brilliant for avoiding having to manually type these (it even auto-completes joins based on foreign keys), but isn't free. SQL server 2008 supports intellisense out of the box, although it isn't quite as complete as the redgate version.
Actually sometimes when you are updating one table from another table's data, I think one of the common issues that cause this error, is when you use your table abbreviations incorrectly or when they are not needed. The correct statement is below:
Update Table1
Set SomeField = t2.SomeFieldValue
From Table1 t1
Inner Join Table2 as t2
On t1.ID = t2.ID
Notice that SomeField column from Table1 doesn't have the t1 qualifier as t1.SomeField but is just SomeField.
If one tries to update it by specifying t1.SomeField the statement will return the multi-part error that you have noticed.
It's probably a typo. Look for the places in your code where you call [schema].[TableName] (basically anywhere you reference a field) and make sure everything is spelled correctly.
Personally, I try to avoid this by using aliases for all my tables. It helps tremendously when you can shorten a long table name to an acronym of it's description (i.e. WorkOrderParts -> WOP), and also makes your query more readable.
Edit: As an added bonus, you'll save TONS of keystrokes when all you have to type is a three or four-letter alias vs. the schema, table, and field names all together.
Binding = your textual representation of a specific column gets mapped to a physical column in some table, in some database, on some server.
Multipart identifier could be: MyDatabase.dbo.MyTable. If you get any of these identifiers wrong, then you have a multipart identifier that cannot be mapped.
The best way to avoid it is to write the query right the first time, or use a plugin for management studio that provides intellisense and thus help you out by avoiding typos.
I found that I get these a lot when I try to abbreviate, such as:
Table1 t1, Table2 t2
where t1.ID = t2.ID
Changing it to:
Table1, Table2
where Table1.ID = Table2.ID
Makes the query work and not throw the error.
You probably have a typo. For instance, if you have a table named Customer in a database named Sales, you could refer to it as Sales..Customer (although it is better to refer to it including the owner name (dbo is the default owner) like Sales.dbo.Customer.
If you typed Sales...Customer, you might have gotten the message you got.
If you are sure that it is not a typo spelling-wise, perhaps it is a typo case-wise.
What collation are you using? Check it.
When updating tables make sure you do not reference the field your updating via the alias.
I just had the error with the following code
update [page]
set p.pagestatusid = 1
from [page] p
join seed s on s.seedid = p.seedid
where s.providercode = 'agd'
and p.pagestatusid = 0
I had to remove the alias reference in the set statement so it reads like this
update [page]
set pagestatusid = 1
from [page] p
join seed s on s.seedid = p.seedid
where s.providercode = 'agd'
and p.pagestatusid = 0
Adding table alias in front Set field causes this problem in my case.
Right
Update Table1
Set SomeField = t2.SomeFieldValue
From Table1 t1
Inner Join Table2 as t2
On t1.ID = t2.ID
Wrong
Update Table1
Set t1.SomeField = t2.SomeFieldValue
From Table1 t1
Inner Join Table2 as t2
On t1.ID = t2.ID
I had this issue and it turned out to be an incorrect table alias. Correcting this resolved the issue.
Mine was putting the schema on the table Alias by mistake:
SELECT * FROM schema.CustomerOrders co
WHERE schema.co.ID = 1 -- oops!
I had P.PayeeName AS 'Payer' --,
and the two comment lines threw this error
I actually forgot to join the table to the others that's why i got the error
Supposed to be this way:
CREATE VIEW reserved_passangers AS
SELECT dbo.Passenger.PassName, dbo.Passenger.Address1, dbo.Passenger.Phone
FROM dbo.Passenger, dbo.Reservation, dbo.Flight
WHERE (dbo.Passenger.PassNum = dbo.Reservation.PassNum) and
(dbo.Reservation.Flightdate = 'January 15 2004' and Flight.FlightNum =562)
And not this way:
CREATE VIEW reserved_passangers AS
SELECT dbo.Passenger.PassName, dbo.Passenger.Address1, dbo.Passenger.Phone
FROM dbo.Passenger, dbo.Reservation
WHERE (dbo.Passenger.PassNum = dbo.Reservation.PassNum) and
(dbo.Reservation.Flightdate = 'January 15 2004' and Flight.FlightNum = 562)
Error Code
FROM
dbo.Category C LEFT OUTER JOIN
dbo.SubCategory SC ON C.categoryID = SC.CategoryID AND C.IsActive = 'True' LEFT OUTER JOIN
dbo.Module M ON SC.subCategoryID = M.subCategoryID AND SC.IsActive = 'True' LEFT OUTER JOIN
dbo.SubModule SM ON M.ModuleID = SM.ModuleID AND M.IsActive = 'True' AND SM.IsActive = 'True' LEFT OUTER JOIN
dbo.trainer ON dbo.trainer.TopicID =dbo.SubModule.subModuleID
Solution Code
FROM
dbo.Category C LEFT OUTER JOIN
dbo.SubCategory SC ON C.categoryID = SC.CategoryID AND C.IsActive = 'True' LEFT OUTER JOIN
dbo.Module M ON SC.subCategoryID = M.subCategoryID AND SC.IsActive = 'True' LEFT OUTER JOIN
dbo.SubModule SM ON M.ModuleID = SM.ModuleID AND M.IsActive = 'True' AND SM.IsActive = 'True' LEFT OUTER JOIN
dbo.trainer ON dbo.trainer.TopicID = SM.subModuleID
as you can see, in error code, dbo.SubModule is already defined as SM, but I am using dbo.SubModule in next line, hence there was an error.
use declared name instead of actual name. Problem solved.
My best advise when having the error is to use [] braquets to sorround table names, the abbreviation of tables causes sometimes errors, (sometime table abbreviations just work fine...weird)
I was getting this error and just could not see where the problem was. I double checked all of my aliases and syntax and nothing looked out of place. The query was similar to ones I write all the time.
I decided to just re-write the query (I originally had copied it from a report .rdl file) below, over again, and it ran fine. Looking at the queries now, they look the same to me, but my re-written one works.
Just wanted to say that it might be worth a shot if nothing else works.
When you type the FROM table those errors will disappear.
Type FROM below what your typing then Intellisense will work and multi-part identifier will work.
I faced this problem and solved it but there is a difference between your and mine code. In spite of I think you can understand what is "the multi-part identifier could not be bound"
When I used this code
select * from tbTest where email = sakira#gmail.com
I faced Multi-part identifier problem
but when I use single quotation for email address It solved
select * from tbTest where email = 'sakira#gmail.com'
I had exactly the same issue, and similar to your coding I had missed out the FROM field, once it is added, the query knows what table to read the data from
Mine worked after removing square brackets in a SUBSTRING method. I changed from
SUBSTRING([dbo.table].[column],15,2)
to
SUBSTRING(dbo.table.column,15,2)
CTRL+SHIFT+R (refreshing the Intellisense) took care of it for me.