I'm debugging an old application in Delphi 5, connected with a recent version of MySql via ODBC connector. When using a CAST conversion function, even the following query:
select cast(1 as char)
returns an empty column without column name.
If I run the query directly into the mysql query analyzer it runs fine, so I suppose the problem is in the ODBC connector or in BDE.
The only information I can find on this is this (emphasis mine):
Connector/ODBC erroneously reported that it supported the CAST() and CONVERT() ODBC
functions for parsing values in SQL statements, which could lead to bad SQL generation
during a query.
Could it be that the connector does not support CAST at all?
Try creating a stored procedure in the database to perform the CAST and hide it from ODBC.
Related
I use Firebird 3.0.4 as a backend to an Access database with an ODBC driver version 2.0.5, both on 64 bit Windows platform. When trying to execute a query containing boolean values in the WHERE clause,the resulting set is empty and I also receive a #-413 error from Access.
Changing the BOOLEAN into SMALLINT, and re-building the backend, the queries execute like a breeze.
What is this?
At first check your query right on the Firebird.
Just grab one of the free "Studios" like "SQL Manager Lite for InterBase & Firebird" and actually check the query.
If it works as it should ...consider "casting" the Boolean value to their numeric form.
when we run select convert(field using utf8) from the MySQL tool (which is on Windows using ODBC) my query works fine. When I run the same query from NIFI (which is on Linux using JDBC) my query does not work. What setting am I missing?
the JDBC connection string is
jdbc:mysql://10.10.x.x:y/warehouse
We are not getting an error. The one field that is being converted is empty.
What is the full query you are running? When you use a function as a field to select from, the name returned is usually something funky, and due to the strict rules on field naming in Avro (which ExecuteSQL converts the data into), it often complains so you have to use an alias, something like select convert(field using utf8) as field from myTable.
But if you're not getting an error, I suspect maybe there's some session variable that is being set on your external MySQL tool and is not being set for NiFi's session. In the upcoming NiFi 1.9.0 release (via NIFI-5780) you'll be able to issue SET statements and such for the session, before executing your main query.
Otherwise, it's possible that the JDBC driver is returning a type to NiFi that it is not handling correctly (although for UTF8 I would expect it would report a String). I tried this with a BINARY(10) field and it works for me (using the latest master, not a released version), so I'm not sure what's going on there.
i try to build an function which returns a json.
I updated my mysql Workbench to 8.0.14 and tried the following code:
SELECT JSON_OBJECT(
'name_field', name_field,
'address_field', address_field,
'contact_age', contact_age
)
FROM contact;
But the following error appears:
Error Code: 1305. FUNCTION datalog.json_object does not exist
I thought that json_object is a standard mysql function, ins't it?
See here:
JSON Object
You're using MariaDB, not MySQL, and your version (MariaDB 10.1) is roughly comparable to MySQL 5.7, with some important differences. Your Workbench version is irrelevant - it's the server version that matters.
https://mariadb.com/kb/en/library/mariadb-vs-mysql-compatibility/
MariaDB 10.1 and above does not support MySQL 5.7's packed JSON objects. MariaDB follows the SQL standard and stores the JSON as a normal TEXT/BLOB. If you want to replicate JSON columns from MySQL to MariaDB, you should store JSON objects in MySQL in a TEXT column or use statement based replication. If you are using JSON columns and want to upgrade to MariaDB, you can either convert the JSON columns to TEXT or use mysqldump to copy these tables to MariaDB. In MySQL, JSON is compared according to json values. In MariaDB JSON strings are normal strings and compared as strings.
MariaDB 10.2.3 adds JSON_OBJECT support. https://mariadb.com/kb/en/library/json_object/
I am building a reporting database and get data in CSV as well as from MS SQL Server. These are mostly personal records, tied together by SSN (well, not really SSN but something very similar). For security reasons, we are not storing the SSN, but rather the SHA2-256 hash of the SSN.
On MySql 5.6, I can simply use the built-in function:
sha2( string, 256).
For MS SQL Express (SQL Server 2008 running on Windows 7) I used this link (http://geekswithblogs.net/hroggero/archive/2009/09/19/strong-password-hashing-with-sql-server.aspx) to write an external UDF.
Each function should return the same string for the same argument .. and it does not. Even more puzzling is that the binary representation seems to be quite different:
MySql Output: bfd6b995588ec54ce16871bc82a7ac86dd43a2c22309ea68e479a50043683937
MSSQL Output: 0x1B4F27012B7F6E7DA6563376E3CB560FCB07FDE2E33C6C3241A5D53885ABCF71
The MSSQL output is clearly a hex encoding (0-9, A-F) of the low and high 4 bit portions of each byte. But how does MySql represent the binary characters?
Ran the MySql queries both through SqlYog and through the DOS command-line ... no difference.
I have checked the MySql documentation and everything else I could find on the web, no luck.
Actually, MySql returns the same hex codes as MSSQL, just in lowercase. I did correct my C# code and now both functions return the same string. Hurrayyyyyyy
I am am currently trying out the Community ODBC Adapter (from TwoConnect) to call stored procedures on a MySQL database.
I have been able to use the MySQL ODBC driver to connect to the database, but when generating the schemas for a stored procedure with input parameters I am getting the following error:
Incorrect Number of arguments for Procedure addupdate_product; expected 7, got 0
This error occurs following the press of the Generate button, with the Query:
addupdate_product()
How to correct the syntax?
SHOW CREATE PROCEDURE addupdate_product; doesn't tell you which parameters to provide, or are they not coming through?
I have now figured out how to use the ODBC Adpater with a MySQL stored procedure that has parameters.
The key to this is not selecting the stored procedure option and instead using the SQL Script option.
Full details can be found here :
http://geekswithblogs.net/StuartBrierley/archive/2010/06/09/biztalk-2009---the-community-odbc-adapter-schema-generation-with.aspx