I have a problem in ASE isql that it can't stop the execution when a negative exponential value is displayed.
select -1.2218952178955078e-006
Does anyone know how I can avoid exponential value by default? Is there a setting available in session or I can do it by changing my locale? Thanks.
Regards,
Jason
Related
I have just been given an assignment for University on databases where I have to use Oracle APEX. For one of my columns in a report, I need to use a format mask. The format mask I need in the form of AAAA00, where A is any letter and 0 is any number.
Trying to get this to work is an issue though. I've heard the syntax for any number is 9 and I assume it's A for the letter, so wouldn't the format mask be AAAA99?
This is what I tried
I tried using it but didn't succeed. When using the form, you can still input anything. I even tried using one of the default date options for the format mask, and that didn't work either.
Any ideas on what to do?
Oracle APEX Format Mask is only for the Number and Date type objects, you can't format strings using it.
Also, Format Masks are for display only, lets say I have a mask 9G9G9G9 in an Interactive Grid column, it would display numbers like : 3,1,4,1. I could go and edit my cell putting 1337, it won't change until I save my report, it will then format itself in my mask and display my number as 1,3,3,7.
I believe you are trying to restrict your user from giving an input other than in your format, (an input mask), I believe this post could help you achieve what you are trying .
I have come through a scenario where the value for a field is loading 'NULL' when actual value in the file is '0' but loading the correct value if the file has a non-zero value. I have used the debugger and read the session log. Everywhere the value is showing '0', but in the table it is loading as 'NULL'. Is this a known issue? Can anyone please help me overcoming this discrepancy.
Did you try writing the output to a file and see the output ? Please give details of the transformation.
In addition, Informatica has a special property which you can set when value is 0 or when value is null.
Check that session property too.
Check if there is anything present when value is 0.
Also, what is the column datatype which you are trying to populate too? Does that column have any constraint to not to accept "0"? check that too.
I agree (as #buzyjess says), writing the output to a text file will make it easy for debugging. So, please let us know how it looks like when you output to a file.
Does anyone know if there is a setting within the app itself that would cause it to only return whole numbers?
Example - query is set up to return data 123456789.26 but is being rounded to a whole number 123456789
I cannot find any settings or options in the program. I was able to get the same results by using the STR command, but I shouldn't have to. My colleagues use other versions of SQL server and some return the decimals while others don't.
The short answer is no, there is no global setting that tells SQL Server to round all numeric values.
There is only one setting that can cause anything like this. However it would happen through truncation rather than a system setting that forces rounding.
Under Tools > Options > Query Results > Results to Text, there is a property called "Maximum number of characters displayed in each column".
Based on your description, I have a feeling this is not the case. Mostly because the default value is 256.
When I browse the cube and pivot Sales by Month ,(for example), I get something like 12345.678901.
Is there a way to make it so that when a user browses they get values rounded up to nearest two decimal places, ie: 12345.68, instead?
Thanks,
-teddy
You can enter a format string in the properties for your measure or calculation and if your OLAP client supports it then the formatting will be used. e.g. for 1 decimal place you'd use something like "#,0.0;(#,0.0)". Excel supports format strings by default and you can configure Reporting Services to use them.
Also if you're dealing with money you should configure the measure to use the Currency data type. By default Analysis Services will use Double if the source data type in the database is Money. This can introduce rounding issues and is not as efficient as using Currency. See this article for more info: The many benefits of money data type. One side benefit of using Currency is you will never see more than 4 decimal places.
Either edit the display properties in the cube itself, so it always returns 2 decimal places whenever anyone edits the cube.
Or you can add in a format string when running MDX:
WITH MEMBER [Measures].[NewMeasure] AS '[Measures].[OldMeasure]', FORMAT_STRING='##0.00'
You can change format string property of your measure. There are two possible ways:
If measure is direct measure -
Go to measure's properties and update 'Format String'
If measure is calculated measure -
Go to Calculations and update 'Format String'
I have just been bitten by issue described in SO question Binding int64 (SQL_BIGINT) as query parameter causes error during execution in Oracle 10g ODBC.
I'm porting a C/C++ application using ODBC 2 from SQL Server to Oracle. For numeric fields exceeding NUMBER(9) it uses __int64 datatype which is bound to queries as SQL_C_SBIGINT. Apparently such binding is not supported by Oracle ODBC. I must now do an application wide conversion to another method. Since I don't have much time---it's an unexpected issue---I would rather use proved solution, not trial and error.
What datatype should be used to bind as e.g. NUMBER(15) in Oracle? Is there documented recommended solution? What are you using? Any suggestions?
I'm especially interested in solutions that do not require any additional conversions. I can easily provide and consume numbers in form of __int64 or char* (normal non-exponential form without thousands separator or decimal point). Any other format requires additional conversion on my part.
What I have tried so far:
SQL_C_CHAR
Looks like it's going to work for me. I was worried about variability of number format. But in my use case it doesn't seem to matter. Apparently only fraction point character changes with system language settings.
And I don't see why I should use explicit cast (e.g. TO_NUMERIC) in SQL INSERT or UPDATE command. Everything works fine when I bind parameter with SQL_C_CHAR as C type and SQL_NUMERIC (with proper precision and scale) as SQL type. I couldn't reproduce any data corruption effect.
SQL_NUMERIC_STRUCT
I've noticed SQL_NUMERIC_STRUCT added with ODBC 3.0 and decided to give it a try. I am disappointed.
In my situation it is enough, as the application doesn't really use fractional numbers. But as a general solution... Simply, I don't get it. I mean, I finally understood how it is supposed to be used. What I don't get is: why anyone would introduce new struct of this kind and then make it work this way.
SQL_NUMERIC_STRUCT has all the needed fields to represent any NUMERIC (or NUMBER, or DECIMAL) value with it's precision and scale. Only they are not used.
When reading, ODBC sets precision of the number (based on precision of the column; except that Oracle returns bigger precision, e.g. 20 for NUMBER(15)). But if your column has fractional part (scale > 0) it is by default truncated. To read number with proper scale you need to set precision and scale yourself with SQLSetDescField call before fetching data.
When writing, Oracle thankfully respects scale contained in SQL_NUMERIC_STRUCT. But ODBC spec doesn't mandate it and MS SQL Server ignores this value. So, back to SQLSetDescField again.
See HOWTO: Retrieving Numeric Data with SQL_NUMERIC_STRUCT and INF: How to Use SQL_C_NUMERIC Data Type with Numeric Data for more information.
Why ODBC doesn't fully use its own SQL_NUMERIC_STRUCT? I don't know. It looks like it works but I think it's just too much work.
I guess I'll use SQL_C_CHAR.
My personal preference is to make the bind variables character strings (VARCHAR2), and let Oracle do the conversion from character to it's own internal storage format. It's easy enough (in C) to get data values represented as null terminated strings, in an acceptable format.
So, instead of writing SQL like this:
SET MY_NUMBER_COL = :b1
, MY_DATE_COL = :b2
I write the SQL like this:
SET MY_NUMBER_COL = TO_NUMBER( :b1 )
, MY_DATE_COL = TO_DATE( :b2 , 'YYYY-MM-DD HH24:MI:SS')
and supply character strings as the bind variables.
There are a couple of advantages to this approach.
One is that works around the issues and bugs one encounters with binding other data types.
Another advantage is that bind values are easier to decipher on an Oracle event 10046 trace.
Also, an EXPLAIN PLAN (I believe) expects all bind variables to be VARCHAR2, so that means the statement being explained is slightly different than the actual statement being executed (due to the implicit data conversions when the datatypes of the bind arguments in the actual statement are not VARCHAR2.)
And (less important) when I'm testing of the statement in TOAD, it's easier just to be able to type in strings in the input boxes, and not have to muck with changing the datatype in a dropdown list box.
I also let the buitin TO_NUMBER and TO_DATE functions validate the data. (In earlier versions of Oracle at least, I encountered issues with binding a DATE value directly, and it bypassed (at least some of) the validity checking, and allowed invalid date values to be stored in the database.
This is just a personal preference, based on past experience. I use this same approach with Perl DBD.
I wonder what Tom Kyte (asktom.oracle.com) has to say about this topic?