Postgresql cannot automatically convert float point data that comes from remote table in format "1,1"
I am trying to connect db2 and postgresql using some fdw extensions. Now I am using odbc_fdw, but odbc always return float types in format "1,1" and postgresql can only use point as delimiter. may be any postgresql settings or odbc configs?
SELECT CAST('1,01000000E+1' as real);
Error code 22P02. Wrong syntax for type real
I expect to automatically convert strings like "1,1" to float using cast. I think without this I won't be able to user foreign tables with float data types
you could do
SELECT string_to_array('1,01000000E+1', ',')::real[]
Related
I am saving the output of my AnyLogic model into an SQL server database. For non-AnyLogic aficionados, AnyLogic is based on Java. However, I am not sure what data types I need to specify for my columns in the database.
So far I am using these:
double in AnyLogic : float in SQL
string in AnyLogic : varchar in SQL
int in AnyLogic : int in SQL
I also have parameters that are of type Option list, which is, if I understand correctly, a form of Java enum. I tried to save those parameters as varchar, but this (obviously) does not work. In addition, my model contains various boolean parameters. For my boolean parameters, I add columns of type bit in SQL by running:
ALTER TABLE myTable
ADD my_bool BIT NOT NULL DEFAULT 0;
However, running the model returns this error
SQLServerException: Invalid column name 'false'. Caused by: Invalid column name 'false'
So concretely, how can I export parameters of type Option list and boolean?
This addresses the original question which was tagged MySQL.
I don't know all the issues around "option list". Seems like a string (with a length such as varchar(255)) would work. You can also look into the built-in enum type, although I would not normally recommend using enums.
I would recommend using boolean instead of bit as the equivalent for boolean. Seems more mnemonic.
That said, MySQL understands false as a constant. You can check this by running:
select false
This also works:
select "false"
However, this returns the error that you specify:
select `false`
I suspect that the code being generated is using this construct. You will need to look at the code -- and you might need to figure out some other way of handling this. In MySQL you can use 0 for false and that might fix your problem.
The AnyLogic database is a standard HSQLDB database (not something proprietary) but they've added AnyLogic client functionality to define 'column types' as though they are Java types (with special types for option lists and compiled-on-the-fly-and-run Java code).
If you look at the db.script file (HSQLDB just stores the persistent DB data as an SQL script which creates the tables and INSERTs the values) you can see the underlying HSQLDB types which map closely to SQL Server types.
boolean --> BOOLEAN
double --> DOUBLE
int --> INT
String --> VARCHAR(16777216)
Date --> TIMESTAMP
Code --> VARCHAR(16777216)
Option List --> VARCHAR(255)
NB: The 'Java column types' are supposed to make it easier for a non-technical user to understand what they will get from a Java perspective when querying that column but, for example, they are confusing in that queries will return Java nulls for missing values, so a boolean column actually effectively returns a Boolean.
That should help.
I managed to address part of my problem. I am now able to store String variables from Java into my SQL database. The issue was due to incorrect use of quotations.
Java uses double quotations for String variables (e.g.: ""). SQL expects single quotations (e.g.: '') for string-like columns such as varchar() and char()
I had to amend my SQL query to this:
String insertTableSQL = "INSERT INTO test (my_string) VALUES(" +" '"+my_variable_string+"' )";
Note that my_variable_string is a derivative of a Java enum, which I obtained by executing String my_variable_string= my_enum.name();
How to convert wkt to oracle sql
I am using:
SELECT SDO_GEOMETRY('POINT(-121.909315288067 37.3618668002592)',4326) as station_geom_oracle FROM dual
i got MDSYS.SDO_GEOMETRY
Run on:
Java(TM) Platform 1.8.0_151
Oracle IDE 19.1.0.094.2042
Versioning Support 19.1.0.094.2042
I came here from your other question, and you've done it right. The query result is just telling you that you've created a geometry object. There's no way of showing a geometry object in a table so it just gives the data type in square brackets. You could try converting it back into WKT to confirm that it's worked using the SDO_UTILS.TO_WKTGEOMETRY(geom) function. If that looks ok try using SDO_UTILS.SDO_DISTANCE to calculate distance between them.
What is the correct syntax when creating a table in Access with SQL? I have tried DECIMAL, DOUBLE, NUMBER, INT... nothing lets me create an integer category with limiters.
Example:
CREATE TABLE NONGAME (
ITEM_NUM CHAR(4) NOT NULL PRIMARY KEY,
DESCRIPTION CHAR(30),
ON_HAND NUMBER(4), <------- DOES NOT WORK!
CATEGORY CHAR(3),
PRICE DECIMAL(6,2), <------- DOES NOT WORK!
ANYTHING DOUBLE(4,2) <------- DOES NOT WORK!
);
MICROSOFT ACCESS DATA TYPES
The following table shows the Microsoft Access data types, data types used to create tables, and ODBC SQL data types. Some types have limitations, outlined following the table.
Microsoft Access data type Data type (CREATE TABLE) ODBC SQL data type
~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~
BIGBINARY[1] LONGBINARY SQL_LONGVARBINARY
BINARY BINARY SQL_BINARY
BIT BIT SQL_BIT
COUNTER COUNTER SQL_INTEGER
CURRENCY CURRENCY SQL_NUMERIC
DATE/TIME DATETIME SQL_TIMESTAMP
GUID GUID SQL_GUID
LONG BINARY LONGBINARY SQL_LONGVARBINARY
LONG TEXT LONGTEXT SQL_LONGVARCHAR[2]
MEMO LONGTEXT SQL_LONGVARCHAR[2]
NUMBER (FieldSize= SINGLE) SINGLE SQL_REAL
NUMBER (FieldSize= DOUBLE) DOUBLE SQL_DOUBLE
NUMBER (FieldSize= BYTE) UNSIGNED BYTE SQL_TINYINT
NUMBER (FieldSize= INTEGER) SHORT SQL_SMALLINT
NUMBER (FieldSize= LONG INTEGER) LONG SQL_INTEGER
NUMERIC NUMERIC SQL_NUMERIC
OLE LONGBINARY SQL_LONGVARBINARY
TEXT VARCHAR SQL_VARCHAR[1]
ARBINARY VARBINARY SQL_VARBINARY
[1] Access 4.0 applications only. Max 4000 B. Behaviour similar to LONGBINARY.
[2] ANSI applications only.
[3] Unicode and Access 4.0 applications only.
Note: SQLGetTypeInfo returns ODBC data types. It will not return all Microsoft Access data types if more than one Microsoft Access type is mapped to the same ODBC SQL data type. All conversions in Appendix D of the ODBC Programmer's Reference are supported for the SQL data types listed in the previous table.
Limitations on Microsoft Access data types
BINARY**, **VARBINARY**, and **VARCHAR: Creating a BINARY, VARBINARY, or VARCHAR column of zero or unspecified length actually returns a 510-byte column.
BYTE: Even though a Microsoft Access NUMBER field with a FieldSize equal to BYTE is unsigned, a negative number can be inserted into the field when using the Microsoft Access driver.
CHAR**, **LONGVARCHAR**, and **VARCHAR: A character string literal can contain any ANSI character (1-255 decimal). Use two consecutive single quotation marks ('') to represent one single quotation mark ('). Procedures should be used to pass character data when using any special character in a character data type column.
DATE: Date values must be either delimited according to the ODBC canonical date format or delimited by the datetime delimiter (#). Otherwise, Microsoft Access will treat the value as an arithmetic expression and will not raise a warning or error.
For example, the date "March 5, 1996" must be represented as {d '1996-03-05'} or #03/05/1996#; otherwise, if only 03/05/1993 is submitted, Microsoft Access will evaluate this as 3 ÷ 5 ÷ 1996. This value rounds up to the integer 0, and since the zero day maps to 1899-12-31, this is the date used.
A pipe character (|) cannot be used in a date value, even if enclosed in back quotes.
GUID: Data type limited to Microsoft Access 4.0.
NUMERIC: Data type limited to Microsoft Access 4.0.
(More information at the Source)
Limitations on ODBC Desktop Driver data types
The Microsoft ODBC Desktop Database Drivers impose the following limitations on data types:
All data types Type conversion failures might result in the affected column being set to NULL.
BINARY Creating a zero-length BINARY column actually returns a 255-byte BINARY column.
DATE The DATE data type cannot be converted to another data type (or itself) by the CONVERT function.
DECIMAL (Exact Numeric)** Not supported.
Floating-Point Data Types The number of decimal places in a floating-point number may be limited by the number format set in the International section of the Windows Control Panel.
NUMERIC Supports maximum precision and a scale of 28.
TIMESTAMP The TIMESTAMP data type cannot be converted to itself by the CONVERT function.
TINYINT: TINYINT values are always unsigned.
Zero-Length Strings: When a dBASE, Microsoft Excel, Paradox, or Textdriver is used, inserting a zero-length string into a column actually inserts a NULL instead.
(Source)
More Information:
MSDN : Create and Delete Tables and Indexes Using Access SQL
MSDN : CREATE TABLE Statement (Microsoft Access SQL)
Microsoft Docs : Microsoft Access Data Types
Microsoft Docs : Data Type Limitations
Microsoft Docs : Converting between ODBC and SQL Server data types
Microsoft Docs : Limitations of SQL ODBC Desktop Drivers
Wikipedia : Open Database Connectivity (ODBC)
Small addendum by Erik:
You can actually use the Decimal data type in CREATE TABLE queries. However, this requires your statement to be executed either using ADO, or on a database that's been set to use ANSI-92 compatible syntax.
To set your database to ANSI-92 compatible syntax:
Go to File -> Options. Open the tab Object Designers. Go to Query Designer, and under SQL Server Compatible Syntax (ANSI 92), check This Database. Now you can just execute the query. Note that this affects all queries in the database, and affects queries in various ways.
To execute a query using ADO:
In the VBA Immediate Window, execute the following line:
CurrentProject.Connection.Execute "CREATE TABLE NONGAME (ITEM_NUM CHAR(4) NOT NULL PRIMARY KEY, PRICE DECIMAL(6,2));"
Of course, you can execute more complex queries using ADO.
DECIMAL and DOUBLE cannot be used in Access. For a "price", CURRENCY is the best bet. For my other integer, I just used NUMBER and gave it no limiters.
We use DB2 as our main production database, but we use SQL Server for many other things i.e. to do integration between other customers and vendors via EDI etc.
I have a table in SQL with SO numbers and I try to make a lookup in DB2 to get all the invoices for the SO's in my table, so here's what I did.
Created a connection to the DB2 using the Microsoft® OLEDB Provider for DB2
Created a data fllow with a source using a SQL Server connection.
Added a Data Conversion Transformation trying to convert the INT so value to a decimal with a precision of 12, but I couldn't change a precision in a DT_DECIMAL, so the only datatype that I have the option to change the precision is DT_NUMERIC.
Added a lookup transformation to lookup the data withing DB2.
Now when i try to create the join between the source table and DB2 I get an error Cannot map the input column, 'so', to the lookup column, 'orno', because the data types do not match.
According to Microsoft this is not a bug and they suggest to use the DT_NUMERIC where you can change the precision.
If I try to convert the SO to a DT_DECIMAL without changing the precision I'd get the same error mentioned above.
Is there any way to work around the limitations from SSIS and change the precision in a DT_DECIMAL conversion so I could do the match?
Or any other suggestions?
The simple answer is to change the connection property in the DB2 connection to treat DECIMAL as NUMERIC.
See bellow
Sybase ODBC driver have an issue with the decimal data type.
For example, when an application is trying to save in the database a decimal value occurs this error:
ERROR [22018] [DataDirect][ODBC Sybase Wire Protocol driver][SQL Server]Implicit conversion from datatype 'VARCHAR' to 'DECIMAL' is not allowed. Use the CONVERT function to run this query.
Same error occurs when you trying to pass decimal parameter to stored procedure.
How we can fix it using NHibernate or Fluent NHibernate?
Thank you.
I haven't found simple solution for this. I changed in xml's and POCO's System.Decimal to System.Double and it works. I tried add own sql-insert and sql-update in xml files with CONVERT but it didn't work well (eg. value 5.15 was changed to 515).
The Database does not support implicit conversion of char , varchar to decimal . This has the same behaviour for JDBC . Please use Convert function and the run the query .