I noticed that I cannot save NAs to my DB, where price is a float variable. I found that changing column type to double will help, however, it did not help. The sam issue for varchar variables.
dbSendUpdate(CONNECTION,paste("INSERT INTO DB (Price) values (",
paste("'",NA,"'", sep=""),
");"))
Error in .local(conn, statement, ...) : execute JDBC update query
failed in dbSendUpdate ([Vertica]VJDBC ERROR: Invalid syntax
for float: "NA")
How can I export data showing NAs as empty cells in the DB?
Related
I have a question about powercenter message code: RR-4035. I have a mapping in which i am using a sql override query, this error is in sql override. This mapping is failing with an error,
'[IBM][CLI DRIVER]CLIO113E SQLSTATE 22007:An invalid datetime format
was detected, that is an invalid string representation or value was
specified'.
> Database driver error:
Function name:Fetch
SQL STMNT:
select s.employee_record_id,s.employee_id,s.record_origin,
cnt.employee_contract_id,cnt.employee_contract_efctv_dt,cnt.employee_contract_term_dt,club.employee_club
from
employee_main_info s
inner join
(select
employee_id,record_origin,employee_contract_term_dt,employee_contract_efctv_dt
from employee_perm
union
select
employee_id,record_origin,employee_contract_term_dt,employee_contract_efctv_dt
from employee_temp
) cnt on s.employee_id=cnt.employee_id,
employee_club_data club
where
club.employee_id=s.employee_id
and (cnt.employee_contract_efctv_dt <=sysdate or cnt.employee_contract_efctv_dt<'2016-01-01')
and s.employee_record_term_dt>sysdate;
native error code= -99999
I have tried everything, my previous mappings have run fine with the same datetime formats but this one is failing. One thing i have noticed is that if i remove all the transformations in between the source qualifier and target the mapping succeeds and data gets loaded to target, but as soon as i put any lookups or expressions between source qualifier and target except a pass through expression, the mapping fails again.
Any suggestion, any help regarding this is appreciated.
We've seen this error occurring when SELECTing from a table with a timestamp column via the IBM Data Server ODBC/CLI driver. It only happened on one Windows machine and we were able to make the error disappear by changing the regional setting main selection from Israel to USA.
While not tested yet, it may be that the IBM DB2 ODBC configuration option DateTimeStringFormat or the attributes SQL_ATTR_DATE_FMT and SQL_ATTR_TIME_FMT can be used to force a specific format (such as JIS). See https://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.1.0/com.ibm.db2.luw.apdv.cli.doc/doc/r0011525.html
I am getting this error and don't understand why:
Error Executing Database Query. [Macromedia][SQLServer JDBC
Driver][SQLServer]Invalid column name 'buildno'. The error occurred
in C:/data/wwwroot/webappsdev/cfeis/redbook/redbook_bio_load.cfm: line
10
8 : select *
9 : from redbook_bio
10 : where build_num = '#session.build_num#'
11 : </cfquery>
12 :
VENDORERRORCODE: 207 SQLSTATE: 42S22 SQL: select * from
redbook_bio where buildno = '4700' DATASOURCE: xxxx
******"
It is saying buildno is an invalid column name, but I do not have that name in my query. I used to, but changed both the column in the database and the column name in the query to build_num. You can see my exact code with line numbers, and that there is no 'buildno' in there. But looking at the SQL statement below that, it is still trying to use 'buildno'.
I had my editor check the directory for anywhere it says buildno and no results came back. I have restarted the CF Service and cleared the cache. Why would it still be trying to run it with buildno instead of build_num like the code says?
There was a cfquery cache setting in the Administrator. We had it set to 100. Apparently clearing the cache template and component cache doesn't clear the cfquery cache. I changed the query name and it fixed the problem. It most likely could have been fixed by setting the cfquery cache value to 0.
The goal of my code is to return a count of the number of rows in a table based on one specific parameter.
Here is code that works:
######### SQL Commands
### Connect to the SQL Database
my $dbh = DBI->connect($data_source, $user, $pass)
or die "Can't connect to $data_source: $DBI::errstr";
### Prepare the SQL statement and execute
my $sth1 = $dbh->selectrow_array("select count(*) from TableInfo where Type = '2'")
or die "Can't connect to $data_source: $DBI::errstr";
### Disconnect from Database statements are completed.
$dbh->disconnect;
######### end SQL Commands
print $sth1;
This will successfully print a number which is 189 in this instance.
When I try to use the same code but change the "Type = '2'" (which should return a value of 2000) I get the following error:
DBD::ODBC::db selectrow_array failed: [Microsoft][ODBC Driver 11 for SQL Server]Numeric value out of range (SQL-22003) at ./getTotalExpSRP.cgi line 33, <DATA> line 225.
Can't connect to dbi:ODBC:BLTSS_SRP: [Microsoft][ODBC Driver 11 for SQL Server]Numeric value out of range (SQL-22003) at ./getTotalExpSRP.cgi line 33, <DATA> line 225.
I've search everywhere but I cannot find out why this happens.
From the symptom of the issue I would guess that there is a limit to the size of the results returned but I cannot find any supporting evidence of this.
I have run a trace on my Microsoft SQL 2005 server and can confirm that the sql statement is being run properly with no errors.
I've viewed my odbc trace log but unfortunately I cannot derive any useful information when comparing a working example to the failed one.
Any help would be appreciated!!
Thanks,
Now we've seen the trace I can explain this. DBD::ODBC calls SQLDescribeCol and is told:
DescribeCol column = 1, name = , namelen = 0, type = unknown(0), precision/column size = 10, scale = 0, nullable = 1
display size = 11
Then it calls SQLColAttribute and is told the column size is 4. Since the column type was unknown (why the driver did that I'm not sure) DBD::ODBC decides to bind the column as a char(4) and so as soon as the count is > 3 digits it will overflow.
The version of DBI and DBD::ODBC being used here is really old and I suspect the latest versions will cope better with this.
Numeric value out of range is a type conversion error. Is TYPE supposed to be a number of a character/string? If it should be a number, use a number
my $sth1 = $dbh->selectrow_array(
"select count(*) from TableInfo where Type=2") # Type=2, not Type='2'
or use placeholders and let Perl and the database driver worry about type conversions
my $sth = $dbh->prepare("select count(*) from TableInfo where Type=?");
$sth->execute(2);
$sth->execute('2'); # same thing
my $st1 = $sth->fetchall_arrayref;
Good day!
I get this error:
SQL STATE 37000 [Microsoft][ODBC Microsoft Access Driver] Syntax Error
or Access Violation, when trying to run an embedded SQL statement on
Powerscript.
I am using MsSQL Server 2008 and PowerBuilder 10.5, the OS is Windows 7. I was able to determine one of the queries that is causing the problem:
SELECT top 1 CONVERT(DATETIME,:ls_datetime)
into :ldtme_datetime
from employee_information
USING SQLCA;
if SQLCA.SQLCODE = -1 then
Messagebox('SQL ERROR',SQLCA.SQLERRTEXT)
return -1
end if
I was able to come up with a solution to this by just using the datetime() function of PowerBuilder. But there are other parts of the program that is causing this and I am having a hard time in identifying which part of the program causes this. I find this very weird because I am running the same scripts here in my dev-pc with no problems at all, but when trying to run the program on my client's workstation I am getting this error. I haven't found any differences in the workstation and my dev-pc. I also tried following the instructions here, but the problem still occurs.
UPDATE: I was able to identify the other script that is causing the problem:
/////////////////////////////////////////////////////////////////////////////
// f_datediff
// Computes the time difference (in number of minutes) between adtme_datefrom and adtme_dateto
////////////////////////////
decimal ld_time_diff
SELECT top 1 DATEDIFF(MINUTE,:adtme_datefrom,:adtme_dateto)
into :ld_time_diff
FROM EMPLOYEE_INFORMATION
USING SQLCA;
if SQLCA.SQLCODE = -1 then
Messagebox('SQL ERROR',SQLCA.SQLERRTEXT)
return -1
end if
return ld_time_diff
Seems like passing datetime variables causes the error above. Other scripts are working fine.
Create a transaction user object inherited trom transaction.
Put logic in the sqlpreview of your object to capture and log the sql statement being sent to the db.
Instantiate it, connect to the db, and use it in your embedded sql.
Assuming the user gets the error you can then check what was being sent to the db and go from there.
The error in your first statement should be the second parameter to CONVERT function.
It's type is not a string, it's type is an valid expression
https://learn.microsoft.com/en-us/sql/t-sql/functions/cast-and-convert-transact-sql
So I would expect that your
CONVERT(DATETIME,:ls_datetime)
would evaluate to
CONVERT(DATETIME, 'ls_datetime')
but it should be
CONVERT(DATETIME, DateTimeColumn)
The error in your second statement could be that you're providing an wrong datetime format.
So please check if your error still occurs when you use this function
https://learn.microsoft.com/en-us/sql/t-sql/statements/set-dateformat-transact-sql
with the correct datetime format you're using
When retriving Excel sheet Named region it returns spurious column names
OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "(null)" returned message "No value given for one or more required parameters.".
Msg 7320, Level 16, State 2, Line 1
Cannot execute the query "SELECT `Tbl1005`.`CUSTOMER` AS `Col1031`,`Tbl1005`.`NAME` AS `Col1032`,`Tbl1005`.` 1AA00` AS `Col1033`,`Tbl1005`.` 1AB00` AS `Col1034`,`Tbl1005`.` 1AC00` AS `Col1035`,`Tbl1005`.` 1AD00` AS `Col1036`,`Tbl1005`.` 1AE00` AS `Col1037`,`Tbl1005`.` 1AF00` AS `Col1038`,`Tbl1005`.` 1AG00` AS `Col1039`,`Tbl1005`.` 1AH00` AS `Col1040`,`Tbl1005`.` 1AL00` AS `Col1041`,`Tbl1005`.` 1AM00` AS `Col1042`,`Tbl1005`.` 1AN00` AS `Col1043`,`Tbl1005`.` 1AO00` AS `Col1044`,`Tbl1005`.` 1AP00` AS `Col1045`,`Tbl1005`.` 1AQ00` AS `Col1046`,`Tbl1005`.` 1ZA00` AS `Col1047`,`Tbl1005`.` 1ZD00` AS `Col1048`,`Tbl1005`.` 4AN00` AS `Col1049`,`Tbl1005`.` 4AO00` AS `Col1050`,`Tbl1005`.` 4ZB00` AS `Col1051`,`Tbl1005`.` 5ZA00` AS `Col1029` FROM `CPGROUPS` `Tbl1005`" against OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "(null)".
How do I reslove this ?
I ran into this with a sheet that had leading spaces on the first row, used as the field name. The spreadsheet was setup as a linked server
The error message was:
Msg 7320, Level 16, State 2, Line 1
Cannot execute the query "SELECT Tbl1002.Participant AS Col1019
FROM DATASET$ Tbl1002" against OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "XXXXX".
After the leading space was removed it worked.
The linked server was setup using:
exec sp_addlinkedserver #server = N'XXXXX',
#srvproduct=N'Excel', #provider=N'Microsoft.ACE.OLEDB.12.0',
#datasrc=N'\\somewhere\some_dir\mysheet.xlsx',
#provstr=N'EXCEL 12.0;Hdr=Yes' ;
I received this same error for a query to dBase. The error is caused by hitting the 255-column limit for the query result from OPENDATASOURCE. I believe the message is just from an internal call for SQL Server loading the results into memory and parsing them into a result set. They don't represent real column names or anything related to the final output.
I resolved the issue in my case by specifying a hard-coded column list with less than 255 total field names.
Hard coding column names is not an option for me as I would neither know number of columns nor their names before hand.
I resoloved the issue by specifying
select * from OpenDataSource('Microsoft.ACE.OLEDB.12.0','Data Source="\xxxx\x.xls";Extended Properties="Excel 12.0;HDR=Yes;IMEX=1"')...cpGroups
and Allow Inproc = True, Level Zero only=1 on the Provider (ACE.Oledbb.12.0)in the SQL Server
Hope what i learnt can help somebody
Regards
The error went away for me when I removed leading spaces in field names as mentioned by #Jim, i.e. column headings in the spreadsheet , but also:
Duplicated field names - I think this was the biggest problem
Trailing field names