error: too many many input arguments matlab - sql

I am trying to execute a Sql query in matlab. The sql uses 'select' command for selecting a particular row using a columnname which matches a value that is stored in variable given in the following code.
When I execute this , I get an error : Error using ==> database.exec Too many input arguments.
q=value;%computed value.
conn1=database('Dbname','','');
fna=exec(conn1,'select * from table1 where ImageName="',q,'"');
fna=fetch(fna); fda=fna.data;

You are passing four input arguments, the last three ones must be concatitated to one sql command.
sqlquery=['select * from table1 where ImageName="',q,'"'];
fna=exec(conn1,sqlquery);

in the matlab manual it says that exec has the following syntax:
curs = exec(conn,sqlquery)
curs = exec(conn,sqlquery,qTimeOut)
You have four parameters in the exec functions, that's what the error means!

Related

DB2 WITH RETURN in even Simple Stored Procedure generates " Clauses not valid in same definition."

Im at a loss right now because even on the most simple statement,
BEGIN
DECLARE rs1 CURSOR WITH RETURN FOR
select * from table1;
END
WITH RETURN is generating a
SQL Error [42613]: [SQL0628] Clauses not valid in same definition.
The Documentation https://www.ibm.com/docs/en/i/7.3?topic=codes-listing-sql-messages says:
Clauses specified to define the attributes of a column, a sourced function, a procedure, a trigger, or an index are not valid. One of the following has occurred:
WITH RETURN is specified for a cursor in a compound (dynamic) statement.
How is this Select statement supposed to be called for a Cursor without being considered a dynamic statement?
See documentation
WITH RETURN
Specifies that the result table of the cursor is intended to be used as a procedure result set. If the DECLARE CURSOR statement is not
contained within the source code for a procedure, the clause is
ignored.

Execute SQL Task Error: Executing the query failed with the following error: "Incorrect syntax near ''."

I am working on a SSIS package that rejects already loaded files & load only new files to table.
I used for each loop and exceute SSQL to validate if the files are already loaded. When I evaluate
the expression of Execute SQL Task, it evaluates fine. But When I run the paackage I get the following error.
[Execute SQL Task] Error: Executing the query "DECLARE #FileName VARCHAR(100)
SET #FileName=Custo..." failed with the following error: "Incorrect syntax near ''.".
Possible failure reasons: Problems with the query, "ResultSet" property not set correctly,
parameters not set correctly, or connection not established correctly.
The Expression I used in the Execute SQL task is :
"DECLARE #FileName VARCHAR(100)
SET #FileName="+#[User::FileName]+"'
IF EXISTS (SELECT 1
FROM [dbo].[FileLoadStatus]
WHERE filename =#FileName)
BEGIN
SELECT 1 AS FileExistsFlg
END
ELSE
BEGIN
Select 0 AS FileExistsFlg
END"
screen shot of the execute SQL Task
I really apprecaite if you can tell where the problem is ?
You could simplify your expression a little bit to make clear where the SSIS variable is being used:
"SELECT COUNT(*) AS FileExistsFlg
FROM (
SELECT TOP(1) *
FROM
dbo.FileLoadStatus
WHERE
[filename] = '" + #[User::FileName] + "'
) x;"
On the other hand for the SQL Task you could use a standard parameterized query. Assuming you are using an OLEDB connection, the parameter placeholder is the ? sign. No expression is needed and the equivalent Direct Input for the task is:
SELECT COUNT(*) AS FileExistsFlg
FROM (
SELECT TOP(1) *
FROM
dbo.FileLoadStatus
WHERE
[filename] = ?
) x;
With OLEDB you have to map your variable to the placeholder by position (zero based) so in this case the Parameter Name is the number zero. The other properties depend on your metadata and correspond to the variable you would have declare in SQL...
This is less error prone, clearer and reusable for multiple calls as it generates a Prepared Statement.
If your connection type was ADO.Net, the mapping is name based. So check the documentation for the Parameter names and markers for each connection type.

Sybase - How To Output Variable Contents To File

I'm writing a procedure in Sybase using Interactive SQL. The proc contains several SELECT statements that store the results in variables, eg
DROP VARIABLE IF EXISTS #totalRows;
CREATE VARIABLE #totalRows LONG VARCHAR;
SELECT COUNT(*) INTO #totalRows FROM <MyTable>;
I'd like to be able to output the results of this query to a CSV file but I get an error when trying to run the following statement
DROP VARIABLE IF EXISTS #totalRows;
CREATE VARIABLE #totalRows LONG VARCHAR;
SELECT COUNT(*) INTO #totalRows FROM <MyTable>;
OUTPUT TO 'C:\\temp\\TEST.CSV' FORMAT ASCII DELIMITED BY ';' QUOTE '' WITH COLUMN NAMES;
The error reads
Could not execute statement.
Syntax error near 'OUTPUT' on line 4.
SQLCODE=-131, ODBC 3 State="42000".
Line 1, column 1
If I remove the OUTPUT TO section of the query it runs fine. Is it possible in Sybase to write the contents of a variable to an external file in this manner?
Seems like, 'OUTPUT' clause is not supported by Sybase.
As a workaround, you may run this query using some text-based tool (like sqlite) and redirect (>) the output into file, if you happen to use linux box at your client end.
Or, you may add ODBC data source (which will require sybase ODBC-driver) corresponding to your DB in Windows and use MS Excel embedded tool Microsoft Query (Data -> From other sources -> From Microsoft Query) in order to export your query result directly into excel datasheet, which you may save as CSV.
OUTPUT TO is a dbisql command, i.e. a directive for the dbisql client utility. It is not a SQL statement. If you try to execute this with anything other than dbisql, you'll get an error.
BTW -- I believe the OUTPUT clause must follow the semicolon that terminates the SELECT stmt, i.e. not have a line break in between.
Need add select variable before output statement
DROP VARIABLE IF EXISTS #totalRows;
CREATE VARIABLE #totalRows LONG VARCHAR;
SELECT COUNT(*) INTO #totalRows FROM <MyTable>;
SELECT #totalRows; --select variable before output
OUTPUT TO 'C:\\temp\\TEST.CSV' FORMAT ASCII DELIMITED BY ';' QUOTE '' WITH COLUMN NAMES;

Pro C dynamic SQL query

I have to execute the following query using Pro C to get the output and den display the output to the user.
i tried the following code snippet:
int count=0;
char query1[100]="select count(code) from customer where customer_type='a';";
EXEC SQL ALLOCATE DESCRIPTOR 'out' ;
EXEC SQL PREPARE statement FROM :query1 ;
EXEC SQL DESCRIBE OUTPUT statement USING DESCRIPTOR 'out' ;
EXEC SQL SET DESCRIPTOR 'out' VALUE 1 TYPE = :data_type,
LENGTH = :data_len, DATA = :count ;
EXEC SQL DECLARE c CURSOR FOR statement ;
EXEC SQL OPEN c ;
EXEC SQL FETCH c INTO DESCRIPTOR 'out' ;
EXEC SQL GET DESCRIPTOR 'out' VALUE 1 :count = DATA;
EXEC SQL CLOSE c ;
printf("%-8d ",count);
but the output i get is always 0.
How shall i proceed to get the proper output??
can anyone help pls...
It is quite possible you have some errors in there that arn't getting noticed.
Use the EXEC SQL WHENEVER to get some error checking going on.
The one thing that jumps out at me is the semicolon at the end of the query1 value. If I recall correctly, Pro*c will barf on it.
I would strongly recommend against using this method of Pro*C dynamic SQL (Oracle dynamic SQL method 4) unless you can possibly avoid it.
The only case you should need to use this method is when you are using dynamically generated SQL and you don't know how many host variables will be used. E.g. You don't know how many columns will be in the SELECT clause.
A fully fledged example of using Oracle dynamic SQL method 4 can be found at http://docs.oracle.com/cd/B28359_01/appdev.111/b28427/pc_15ody.htm#i7419.

Error in SQL stored procedure

I am getting the following error when I execute my stored procedure:
Msg 102, Level 15, State 1, Line 6Incorrect syntax near '2011'.(1 row(s) affected)
Here is the stored procedure:
ALTER PROCEDURE [dbo].[DeliveryFileNames]
AS
BEGIN
SET NOCOUNT ON;
declare #SQL nvarchar(4000)
Create Table #DelivTemp(
Style nvarchar(50),
Material nvarchar(50),
Filename nvarchar(100),
delivered_date date)
set #SQL=
N'insert into #DelivTemp
Select distinct Style,Material,filename
from OPENQUERY(GCS_PRODUCTION,
''SELECT LEFT(FILENAME,locate(''''_'''',FILENAME)-1)as Style,
substring_index(filename,''''_'''',2)as Material,filename,
delivered_date FROM view_delivery_log
where delivered_date > ''2011%'' order by Style '')'
exec (#SQL)
drop table dbo.DelivFN
Select * into dbo.DelivFN
from #DelivTemp
END
I am using OpenQuery to update a SQL table from a linked server on SQL Server 2008 R2.
I know that the underscore is a real issue, but I have tried a plethora of options including \, % and both single and double quotes.
Regardless I am getting the same result. I can run the query independently of the stored procedure and achieve the correct results. The filename field referenced several times is formatted 00000000_ABC4_A.png. I am using the underscore to identify the components of the file name that I need for my reporting purposes.
In addition to the the logical error of your date comparison using the % that the others have pointed out, your current issue is a syntactical error.
Since you've got a dynamic sql statement contained within another dynamic sql statement... you'll need to double-escape all of your single quotes... which you did in most of the query, except for the following line:
where delivered_date > ''2011%'' order by Style '')'
Properly escaped, would be:
where delivered_date > ''''2011%'''' order by Style '')'
Which raises the question... why are you building up the string to execute dynamically, instead of just calling the statement directly?
It's the syntax of ''2011%''. This is not a valid date. % being a wildcard means the compiler can't know what to compare against in the WHERE clause. You'd need to use an actual date: i.e. ''2011_01_01'' so the compiler can know what to compare against
I believe the stored proc exec runs under a different session, therefore you won't have access to the temp table anyway. So, it won't matter if you get that sql statement to run. You could always use YEAR(delivered_date) > 2011.
Another approach would be to use the fqn for the linked server to select into and bypass the temp table all together:
SELECT LEFT(FILENAME,locate('_',FILENAME)-1)as Style,
substring_index(filename,'_',2)as Material,filename,delivered_date
FROM [linked_server_name].[db_name].[dbo].view_delivery_log
into dbo.DelivFN