We are migrating our forecasting database from Oracle 10.2 to Oracle 12.1. This means that we have to replace the Oracle ProC 9.2.0.3.0 pre-compiler with ProC 10.2.0.5.0.
All of our application programs are built and run under OpenVMS Alpha 8.4. We have traditionally compiled our programs with /FLOAT=G_FLOAT, the native VAX floating-point format.
A program built with Oracle Pro*C 9.2.0.3.0 and VAX floating-point gives correct results.
A program built with Oracle Pro*C 10.2.0.5.0 and VAX floating-point gives invalid results. We got errors and NaNs for the same programs reading the same data.
A program built with Oracle Pro*C 10.2.0.5.0 and IEEE floating-point gives correct data results.
From the results it appears that the Oracle Pro*C 10.2.x pre-compiler requires that host variables use the IEEE floating-point format.
What do others think? Is there any Oracle documentation on this?
Related
I want to convert the data in one of my columns to another language ... is there any function in sql for translating it?
No, there are no SQL functions/procedures for translating between languages built into the Oracle database.
Oracle Text has features for multi-language indexes; but that is for indexing documents and not for translating them.
Oracle 12c and later also has features for translating between different SQL dialects; but that is not for translating data.
If you want to translate data then you will need 3rd party solution that you can import into the database or external software that you can call from the database.
If I have an Informix DDL script for a database and I want to run this script on Oracle to create the equivalent database with the same structure, indexes, data types and constraints.
What are the steps I should follow to execute the script successfully and what are the factors I should take into consideration during the execution?
I use Informix server version IBM Informix Dynamic Server Version 12.10.FC3.
I use Informix Client SDK version 3.50.
I use Oracle 11g.
It is a non-trivial proposition, in general, to transfer even just DDL between Informix and Oracle. There are numerous detailed differences in the syntax, even if you don't use some of the more exotic types (e.g. user-defined types, or lists or sets or row types). This is written from an Informix perspective; treat statements about Oracle with a mild pinch of salt.
Oracle uses VARCHAR2; Informix doesn't (but some types that Informix use should not be translated to Oracle's VARCHAR — it should be VARCHAR2).
Oracle has one underlying numeric type; Informix has many. However, Oracle recognizes most of the type names.
Oracle's DATE type includes a time component; Informix's does not.
Informix has esoteric types such as DATETIME MONTH TO MINUTE (the canonical odd-ball example) which don't have a ready equivalent in Oracle.
You'll need to scrutinize BYTE, TEXT, BLOB and CLOB types carefully and translate accordingly.
There are probably differences in the limits on some of the types. These may cause issues in translation.
There are nitpicking differences between Informix and the rest of the world in the naming of constraints (Informix puts the constraint name after the constraint; the standard puts the constraint name before it).
…and no doubt many other problems…
There are tools available to assist with migrations from Oracle to Informix. I assume there are tools available to assist with the reverse migration, but I am not familiar with them.
Have a look at the official resources for Informix to Oracle at
http://www.oracle.com/technetwork/database/migration/informix-085032.html
While trying to benchmark Oracle's Database Inmemory, we were looking for publicly available benchmarking data set and tools. The CH-benCHmark suited our requirement exactly, but it has HANA Column Store Dialect as part of the source files.
So, our requirement is to convert these HANA Column Store dialect SQLs to Oracle 12c SQLs. Google search returned the conversion from Oracle to Hana dialect not the reverse.
Has anyone came across this requirement? Is there a simple/direct way to do the conversion?
Any pointers will be much helpful.
Yes I have done this exercise! there's no direct way from HANA Dialect to Oracle Dialect, But you can make use of ORACLE_LOADER and it's semantics to effectively create Oracle Dialect! Only problem you may face would be the flow, where HANA's flow is totally different from Oracle's schema creation flow.
For example:
you can easily use LOAD FROM FILE... syntax in HANA, But you need an externally organized table in case of Oracle.
I have a value in the database which is 2.700000002. When I run a query in Management studio in SQL SERVER 2005 I get 2.7. But when I run in SQL SERVER 2000 query analyzer it comes 2.700000002.
2.70000002 is correct why is SQL SERVER 2005 trying to change the value by rounding it or selecting the floor value?
Exactly the same target server, database, datatype, processor, architecture etc?
If not, it's simply how the tools will display an approximate float value
Most things round off numbers for display.
~$ ghci
Prelude> 2.7
2.7
~$ irb
>> 2.7
=> 2.7
~$ python
>>> 2.7
2.7000000000000002
For interactive use, this is usually good enough — the only person to see the query analyzer is you, so why does it matter? For actual display, you should specify a format anyway. If you really need the exact value of "2.7", then you should be using a decimal type anyway, as countless articles and answers can tell you.
I created a view on a machine using the substring function from Firebird, and it worked. When I copied the database to a different machine, the view was broken. This is the way I used it:
SELECT SUBSTRING(field FROM 5 FOR 15) FROM table;
And this is the output on the machine that does not accept the function:
token unknown: FROM
Both computers have this configuration:
IB Expert version 2.5.0.42 to run the queries and deal with the database.
Firebird version 1.5 as server to database.
BDE Administration version 5.01 installed, with Interbase 4.0 drivers.
Any ideas about why it's behaving differently on these machines?
Make sure Firebird engine is 1.5 and there's no InterBase server running on this same box on the port you expected Firebird 1.5.
Make sure you don't have any UDF called 'substring' registered inside this DB so that Firebird is expecting different parameters.
Different engine versions?
Have you tried naming that expression in the result?
SELECT SUBSTRING(field FROM 5 FOR 15) AS x FROM table;