TO_CHAR not Scientific Notation

I want to convert a number to a string but guarantee that the result will NOT be in scientific notation.
TO_CHAR(num, '9999999999.99999999999999') is not very convenient since the data type of the number is BINARY_DOUBLE and I will not know how many significant figures the number will have.

user3975338 wrote:
So is it safe to say there there is no built in feature that would ever output a the numeric string
'0.00000000000000000000000000000000000000000000000000000000000000000000000000000009'The scientific notation is only a matter of how the particular interface is displaying the number and how your NLS settings are for converting automatically between numbers and varchar.
e.g. in SQL*Plus you can change the format of a column easily...
SQL> ed
Wrote file afiedt.buf
  1  with t as (select cast(1.0000000000000001E-001 as binary_double) as dbl from dual union all
  2             select 4.0144896E+008 from dual union all
  3             select 3.0976E+005 from dual union all
  4             select 2.78784E+006 from dual union all
  5             select 6.4E+001 from dual union all
  6             select 2.7878400000000001E+003 from dual union all
  7             select 2.4909766860524436E-011 from dual union all
  8             select 1.0000000000000001E-001 from dual union all
  9             select 7.7160493827160492E-005 from dual union all
10             select 6.9444444444444436E-004 from dual)
11  --
12  select dbl, dbl2, length(trim(dbl2)) as ldbl
13  from (
14    select dbl, rtrim(rtrim(to_char(dbl,'99999999999999990.999999999999999999999999999'),'0'),'.') as dbl2
15    from t
16*   )
SQL> /
       DBL DBL2                                                 LDBL
  1.0E-001                  0.10000000000000001                   19
4.014E+008          401448960                                      9
3.098E+005             309760                                      6
2.788E+006            2787840                                      7
  6.4E+001                 64                                      2
2.788E+003               2787.8400000000001                       18
2.491E-011                  0.000000000024909766860524436         29
  1.0E-001                  0.10000000000000001                   19
7.716E-005                  0.000077160493827160492               23
6.944E-004                  0.00069444444444444436                22
10 rows selected.
SQL> col dbl format 999999999990.9999999999999999999999999999999
SQL> /
                                          DBL DBL2                                                 LDBL
            0.1000000000000000100000000000000                  0.10000000000000001                   19
    401448960.0000000000000000000000000000000          401448960                                      9
       309760.0000000000000000000000000000000             309760                                      6
      2787840.0000000000000000000000000000000            2787840                                      7
           64.0000000000000000000000000000000                 64                                      2
         2787.8400000000001000000000000000000               2787.8400000000001                       18
            0.0000000000249097668605244360000                  0.000000000024909766860524436         29
            0.1000000000000000100000000000000                  0.10000000000000001                   19
            0.0000771604938271604920000000000                  0.000077160493827160492               23
            0.0006944444444444443600000000000                  0.00069444444444444436                22
10 rows selected.
SQL>... see ... no scientific notation any more.

Similar Messages

  • Converting scientific notation string to number?

    This is raising an error:
    > ToNumber (u201C2.75E-05u201D)
    How do you convert scientific notation strings to numbers?
    This is coming from XML. I can probably have the XML written so that it's not scientific notation.
    Tim

    Here's a not-so-pretty way:
    Local StringVar Array x;
    Local StringVar mantissa;
    Local StringVar exponent := "0";
    // Split into mantissa and exponent parts.
    x:= Split("24.2233E+2", "e", 2, 1);
    mantissa := x[1];
    If (UBound(x) = 2)
    Then
        exponent := x[2];
    // CDbl cannot interpret leading positive sign, so removie
    If Left(mantissa, 1) = "+"
    Then
        mantissa := Right(mantissa, Length(mantissa) - 1);
    If Left(exponent, 1) = "+"
    Then
        exponent := Right(exponent, Length(exponent) - 1);
    // Compute number
    CDbl(mantissa) * 10 ^ CDbl(exponent);
    Sincerely,
    Ted Ueda

  • Decimal Format and Scientific Notation

    I am trying to print numbers in scientific notation using the Decimal Format class. What follows is a simple test program I wrote to find the bug. So far, I have not found a solution.
    import java.text.*;
    public class formatted {
    public static void main (String Arguments[]) {
    DecimalFormat form = new DecimalFormat("0.###E0");
         double numb = 123456.789;
         System.out.println("Nuber is: " +
    form.format(numb));
    The output of this program is... Nuber is: 123456E
    The output is the same if numb is an int, float, or double. If I format the number as "#####.0" or "#####.00" the output is correct. I think that I am following the rules for formatting a number in scientific notation as the process is outlined in the documentation (provided below).
    ***** From Decimal Format under Scientific Notation ***
    Numbers in scientific notation are expressed as the product of a mantissa and a power of ten, for
    example, 1234 can be expressed as 1.234 x 10^3. The mantissa is often in the range 1.0 <= x < 10.0,
    but it need not be. DecimalFormat can be instructed to format and parse scientific notation only via a
    pattern; there is currently no factory method that creates a scientific notation format. In a pattern,
    the exponent character immediately followed by one or more digit characters indicates scientific
    notation. Example: "0.###E0" formats the number 1234 as "1.234E3".
    Anyone understand how the short program is incorrectly written?
    Marc

    The problem is
    format = "0.###E0"
    input number = 123456.789
    output = 123456E (not scientific notation!)
    This is not scientific notation at all. There is no decimal point given and no value in the exponent.
    I understand entirely that by adding more #'es will provide more precision. The bug I have is the output is not printed in the scientific format; other formats work.
    MArc

  • Select Query resulting in Scientific Notation

    Hello all,
    I am running a Select query through a batch file that extracts data from an Oracle database. Several of the fields that I am extracting from contain numbers that are up to 38 digits long. When I extract the data, it converts the numbers into scientific notation and it is important for me to have the entire field. Is there something I can change to my query that will pull the data in its entire form? This is what I'm running now:
    select * FROM ML.APPT where APPTDATE >= to_date('01/1/2010','mm/dd/yyyy'
    I apologize in advance if this has been answered already.
    Thanks!

    >
    When the extractor finishes, it returns the data into a flat file.
    don't quite understand the TO_CHAR function. Does this function mean I need to say something like this: select "TO_CHAR('column name', 99999999999999999999999999999999999999" FROM ML.APPT where APPTDATE >= to_date('01/1/2010','mm/dd/yyyy')
    >
    Yes- if the tool you use to extract the data (your 'extractor') is converting the numeric data to a string then it is responsible for creating the string in the proper format. If the number is an integer that can have as many digits as you have '9's in your sample format string then that is what you need to do.
    Here is how sql*plus (Oracle's tool) will display the data using default settings
    SQL> select 12345678901234567890123456789012345678 no_format,
      2  to_char(12345678901234567890123456789012345678, '99999999999999999999999999
    999999999999') with_format
      3   from dual;
    NO_FORMAT WITH_FORMAT
    1.2346E+37  12345678901234567890123456789012345678
    SQL>
    ----- TOAD will display something similiar but the default uses more decimal digits in the scientific notation data
    NO_FORMAT,WITH_FORMAT
    1.23456789012346E37, 12345678901234567890123456789012345678You can either format the numeric data in the query using TO_CHAR or the 'extractor' can do it when it converts the data to a string.

  • How can I get Numbers 3.2 to recognise 1e-5 as scientific notation?

    I just changed from Numbers '09 (2.3) to Number 3.2 on Mavericks (OS X 10.9.3) and the new version doesn't seem to recognise "e" or "E" as scientific notation. When I set the cell format to scientific and type "0.0015", Numbers returns "1.5×10^-03". I would however prefer to obtain "1.5e-3". And vice versa: if, after setting the cell format to scientific, I type "1.5e-3", it automatically formats the cell as text and I can't get it to recognise it as scientific notation. With "E" instead of "e", the problem is exactly the same. Does anyone know how I can change this setting? I already tried to search for an answer to my question, but couldn't find anything...

    if, after setting the cell format to scientific, I type "1.5e-3", it automatically formats the cell as text and I can't get it to recognise it as scientific notation.
    I can't duplicate the problem here, either when the cells are formatted as Automatic or as Scientific:
    When you type 1.5e-3 are you making sure not to enter a space after the e?  (When I type a space the cell automatically formats as Text.)
    SG

  • Scientific Notation on MID

    having trouble with a
    parsed out excel file.
    We import processor files into our application and do so with maybe 20 different processors.
    However one file is giving us a particular problem, even though the MID colum looks to be  a simple MID like this
    8788840008835  it actually shows up once  extracted like this 8.78884000884E+012 scientific notarion
    this is the only file we have this problem with and even if we go in and reformat the colum in various ways so the column looks correct it still spits out this scientific notation.
    tried number format likwe this  #LSNumberFormat(objSheet.Query.column2, "______")#
    and like this #numberformat(objSheet.Query.column2,'_______________________')#   it that keeps the number from being in scientific notation however it rounds the MID on the last number to the closest zero effectivly ruining the data.
    Any ideas on how to get around this?
    BTW its not the initial extraction thats doing it, we use it on many other excel files with no problems, only this file is giving us this problem
    Thanks in advance for any help

    scrollin,
    Your digits are all there. Just format those cells to either Text or Number. Leading zeros do tend to get lost unless you pre-format to text. You can force the cell format to text on the fly by prefixing your input with a single-quote.
    Regards,
    Jerry

  • Convert from scientific notation

    Can someone help me with this? I cannot get this working even using some of the tips I found on this site and elsewhere:
    Round this and format this with 2 decimals: '-2.58069E-11'.
    Now I realize this would end up -2.58, but it is giving me an error instead.
    Error converting data type varchar to numeric.
    SELECT CAST('2.58069E-11' AS NUMERIC(24,2))
    SELECT CAST('2.58069E-11' AS NUMERIC(24,12))
    I tried 12 just to make sure that there was enough room for the decimals
    If I use ISNUMERIC, it returns 1, so SQL Server considers it a number (at least with that function)
    The next example works, but it is not what I want.
    SELECT CAST('2.58069E-11' AS REAL) just returns the same thing with the 'E', (as REAL, of course)
    In these example I haven't done the rounding yet.
    I get all kinds of negative and positive numbers with different decimal lengths, but the scientific notation is particularly tricky.

    Before I put this to bed, I have found out both the above solutions are wrong when using a regular decimal:
    Try this:
    SELECT CAST(CAST('-1131658.27' AS REAL) AS NUMERIC(24,2))
    And this:
    SELECT CAST(CONVERT(REAL, -1131658.27) as DECIMAL(24,12))
    They both yield -1131658.25, and -1131658.250000000000, respectively.
    This is probably some floating point error, but how do I take care of it?

  • WKT Contains Scientific Notation

    I have a table with an SDO geometry column. Our data is stored in Web Mercator to simplify displaying maps on a web page. My team's preferred way of shuffling geometries around is via its WKT since this is human readable and widely used. So we are fetching the WKT directly from the database using the GET_WKT() method (right term?) on the SDO geoemtry.
    The problem is that when coordinates exceed 10 million in magnitude, those coordinates are represented in E notation (see http://en.wikipedia.org/wiki/Scientific_notation#E_notation). I need to convert this WKT to a .NET object for use with a particular library, and while it supports conversion from WKT, it blows up on the E notation. I'd call it a bug with the library except for the fact that Oracle itself can't parse WKTs with E notation, either. SDO_UTIL.VALIDATE_WKTGEOMETRY returns FALSE for the WKT that GET_WKT() generated, and SDO_UTIL.FROM_WKTGEOMETRY throws an error. I've also tested that SDO_UTIL.SDO_UTIL.TO_WKTGEOMETRY returns the same WKT.
    A large amount of code already depends on the geometry being in WKT format, which means that switching to another format would not be an easy change. For the moment, I'm parsing the WKT using SQL Server's geometry type (see http://msdn.microsoft.com/en-us/library/microsoft.sqlserver.types.sqlgeometry_methods.aspx), and then converting it back to a WKT without E notation using its STAsText() method.
    Is there a way to force Oracle to not return E notation coordinates?
    This is occurring in both of the following versions of Oracle:
    Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
    PL/SQL Release 10.2.0.1.0 - Production
    "CORE     10.2.0.1.0     Production"
    TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
    NLSRTL Version 10.2.0.1.0 - Production
    Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
    PL/SQL Release 11.1.0.6.0 - Production
    "CORE     11.1.0.6.0     Production"
    TNS for 32-bit Windows: Version 11.1.0.6.0 - Production
    NLSRTL Version 11.1.0.6.0 - Production
    Sample SQL:
    The SRID in the following queries does not seem to exist out of the box in version 10 or Oracle. I ran these queries through Oracle SQL Developer.
    Query:
    SELECT MDSYS.SDO_GEOMETRY(2003,3785,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1),MDSYS.SDO_ORDINATE_ARRAY(-13426771.266146,5334024.8870015,-13425624.710722,5326534.0582305,-13412553.978887,5325922.5620044,-13412936.164029,5333719.1388884,-13426771.266146,5334024.8870015)).GET_WKT() FROM DUAL;
    Result:
    POLYGON ((-1.3426771266146E7 5334024.8870015, -1.3425624710722E7 5326534.0582305, -1.3412553978887E7 5325922.5620044, -1.3412936164029E7 5333719.1388884, -1.3426771266146E7 5334024.8870015))
    Query:
    SELECT SDO_UTIL.VALIDATE_WKTGEOMETRY(MDSYS.SDO_GEOMETRY(2003,3857,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1),MDSYS.SDO_ORDINATE_ARRAY(-13426771.266146,5334024.8870015,-13425624.710722,5326534.0582305,-13412553.978887,5325922.5620044,-13412936.164029,5333719.1388884,-13426771.266146,5334024.8870015)).GET_WKT()) FROM DUAL;
    Result:
    FALSE
    Query:
    SELECT SDO_UTIL.FROM_WKTGEOMETRY(MDSYS.SDO_GEOMETRY(2003,3785,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1),MDSYS.SDO_ORDINATE_ARRAY(-13426771.266146,5334024.8870015,-13425624.710722,5326534.0582305,-13412553.978887,5325922.5620044,-13412936.164029,5333719.1388884,-13426771.266146,5334024.8870015)).GET_WKT()) FROM DUAL;
    Result:
    ORA-29532: Java call terminated by uncaught Java exception: java.lang.RuntimeException
    ORA-06512: at "MDSYS.SDO_UTIL", line 172
    29532. 00000 - "Java call terminated by uncaught Java exception: %s"
    *Cause:    A Java exception or error was signaled and could not be
    resolved by the Java code.
    *Action:   Modify Java code, if this behavior is not intended.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

    Hello jpmc26,
    I am going to guess that most of us live our lives between the 180s and have not really noticed this before. I would call it a bug that needs an SR opened but is the bug on the coming or the going? If you look in the Simple Features 1.2.1 specification on pages 52 and 53 they clearly say that an "approximate numeric literal" of mantissa + E + exponent is valid. However, Oracle Spatial does not support the 1.2.1 spec. Rather they support something akin to the 1.1.0 specification. On pages 28 and 29 of that version there is no mention of approximate numeric literals as it first shows up in the 1.2.0 specification.
    So I would say either:
    1) Oracle Spatial supporting only the 1.1.0 specification and not much interested in updating to current specifications, should remove the output of scientific notation from the SDO_UTIL.to_WKTGEOMETRY procedure (match 1.1.0 spec).
    -or-
    2) Oracle Spatial looking forward to future compatibility with new OGC standards, should add support for parsing scientific notation to the SDO_UTIL.from_WKTGEOMETRY procedure (prepare for 1.2.1 spec).
    I guess its a policy decision on their side. Please update the posting as to what they say as I am curious about the topic.
    Many folks have largely abandoned these java-based, outdated, OGC converters. Feel free to search the forum for complaints, myself being one of the complainers. When you said "a large amount of code already depends" on WKT, my first thought was that must be really slow. Writing your own SDO to WKT converter in PLSQL is really easy and I believe that's what most of us have done. The other direction is more challenging but doable - I need to rewrite mine but its works well enough for straightforward stuff.
    Cheers,
    Paul

  • Powershell / Scientific Notation Woes / Formatting Output to Live Excel Sheet

    I have a WMI query in a script that dumps machine information to a live excel sheet.
    I find when I query the model # of the machine using (this line of code from the script):
    $Sheet.Cells.Item($count,4) = (Get-WmiObject win32_computersystem -ComputerName $computer).Model
    The output almost always changes into Scientific Notation, because this is a typical model number :   "3500-E52"
    Is there a way to modify the formatting of the:
    $Sheet.Cells.Item($count,4)
    so that Excel uses "text" formatting for that cell?  I know you can change the fonts etc... but have not been lucky in finding a powershell > excel reference
    that explains how to change a cell or column's formatting beyond the basics.
    I have seen recommendations to others to dump the results queries to a CSV first, and then import into Excel (which would allow a manual change of that column's format).  I'm just
    hoping to bypass the extra "hands on" and format more directly to a sheet in Excel.
    If .csv is the best way to go, I'll muddle through it and change the code.
    Any help is greatly appreciated.
    Ben

    $sheet.Cells(1,1).NumberFormat
    = "@"
    ¯\_(ツ)_/¯

  • Data retrieval in non-scientific notation from Netezza database

    Hi,
    I have a requirement where my BPEL service fetches data from Netezza database. In the database, there is a field which is of type numeric(16,8) and holds values say '0.00000000'. The select query on the table rerieves data in its scientific notation as '0E-8'.
    Please let me know how to retrieve its value in the form of non-scientific notation.
    Thanks in advance.
    Regards,
    Sitara

    hai
      chowdary,
       it is not possible to retrieve data from maintenace view.
    it is only possible to retrive data from a table or database
    / projection views defined ddic.
    Maintenace views are used to maintain data of an application object together.Data from several tables can be joined and summarized data can be seen of this view based on primary key join relationship using SM30.U make any changes  or view the data there only.
    if useful, reward points.
    By
    G.V.K.Prasad
    Edited by: PRASAD GVK on Apr 13, 2008 3:36 PM

  • Scientific notation doesn't display correctly

    Hi, this is just a general question but it's about the Calculator app. The problem is with displaying answers in scientific notation. When I'm in scientific calculator mode, answers displayed on the screen only appear in scientific notation when they are larger than the number of digits that can be displayed. However, whenever I use it to calculate something in which the answer is smaller than the set precision for the number of decimal places, it always gives 0 instead of scientific notation. For example, if I type a number such as 1E19 and press =, then the answer displays correctly as 1E19. However, if I type 1/1E19, and press =, then the answer simply shows up as 0 instead of 1E-19, which is the correct answer in scientific notation. So, it seems that the scientific notation in Calculator simply does not display negative exponents in the scientific notation (I know that I can type such numbers but for some reason, it cannot display them as answers). This is very annoying because I often work with very small numbers, not just very large ones. Is there any way that I can get the scientific notation to display negative exponents when I'm working with very small numbers and when the answer is smaller than the set number of decimal places?

    There are tonnes of possibilities and many websites with suggestions. I tried all sorts of these option (clear cache, clear cookies, anti-virus changes, page style options etc) with no success until eventually I accidentally changed my character encoding autodetect (firefox 6) from "off" to "universal" and everything is fine.

  • Importing data in scientific notation format

    Hi,
    I've got some data files produced by some ancient laboratory software. In the files, numbers are formatted like this:
    +7.60609E-02
    +8.18901E-03
    etc.
    When I import the data into Numbers, Numbers does not seem to recognize that the data points represent numbers, rather than strings (I can't create plots from the data, for example). If I edit the cells to prepend "=" to the entry, then Numbers evaluates the entry as if it were scientific notation (which is what I want), so that +7.60609E-02 becomes 0.760609. Is there a way to indicate to Numbers that the data I am importing is in scientific notation format, and should be treated as such? Because I'm not too excited about manually prepending "=" to everything.
    Thanks

    If the file is a comma separated values file, you have two choices:
    1) Make a Numbers sheet that is formatted the way you want it, including formatting the cells in the column to be scientific.  Drag the file from Finder and drop it on cell A1 of the table or, if not A1, the top-left cell of where you wantthe data to begin in the table, like maybe cell B2. Or,
    2) Open the CSV file with Numbers. After import, select the column of numbers and format it as scientific.

  • Double in Scientific Notation after Marshal

    Hi,
    I have an element defined as an xsd:double. If I try and place a value say 100 into the element and then I marshal it I get an output of <Quantity>100.0</Quantity>... That is fine....
    However, if I put a value in of say 1000000000, I get an output of <Quantity>1.0E9</Quantity> when I marshal.
    Can I turn a setting on (or off) so the output does not get converted into scientific notation?
    -j

    I also verified the XML standard and you are right that the values are legal xsd:double values. What made this a problem for me is that the XSLT functions that use XPATH number() to process these values failed because XPATH specifies that a number is:
    Number ::= Digits ( '.' Digits?)? | '.' Digits
    which does not handle the exponents at all. So the XML documents produced could not be handled by XSLT processors.
    For fun, I redefined my schema definition to replace xsd:double with:
    <xs:simpleType name="simpleDouble">
         <xs:restriction base="xs:double">
              <xs:pattern value="(-)?[0-9]*(.[0-9]+)?" />
         </xs:restriction>
    </xs:simpleType>
    which is essentially a non-exponent based double. JAXB rendered the document, but then the validator complained that the output did not match the pattern. So JAXB does not use this pattern as a method of determining output, only as a method of validation.
    This is why I replaced the DoubleType class for my solution. The alternative of using the jaxb:globalBindings is probably a cleaner approach. I think I'll switch my implementation. Thanks for the pointer!
    -Allan

  • No scientific notation in csv file

    Hi, All
    I have a package is extracting data from DB to CSV file.
    And I made up a column like '48484848484848484', when I load this column into CSV file,
    it shows me scientific notation along with the data.
    How can I get rid of the scientific notation ?
    I've tried data conversion, derived column. Nothing works.
    This really makes my frustrated.
    Thank you in advance.

    Hi,
    In that case, the SQL export process is fine.
    It's just Excel suggesting a scientific notation where it's not needed.
    You can get rid of the scientific notation by forcing your "long" numeric value into a string.
    For example
    "A001","Item code", "123376265892759026"
    instead of
    "A001", "Item code", 123376265892759026
    Sebastian Sajaroff Senior DBA Pharmacies Jean Coutu
    My data souce is like:
    Select '1234567891123' as column1,
              Id  as column2,
                          Name as column3,
    From Table1
    I think I already give column1 as a string. And I also tried to cast column1 to nvarchar or varchar or decimal or numeric, nothing works.

  • Remove scientific notation in report

    I'm calculating a number and placing it in a comment box on a report. This works fine, but one of the numbers has decided to display in scientific notation (1.52666667e-3). The problem is that the comment box is not large enough to display the scientific notation and gives no indication of not fitting into the box. Instead I see 1.52666 with no indication of the exponent. I'd much rather see .001527 however I don't want to force a STR format with "d.dddddd" because most numbers don't need this much precision and I'd probably run into errors for numbers such as 12345 which won't fit into the comment box with forced 6 digit precision. If I can force it out of scientific precision, it'll probably be fine.
    BTW: is there a certain number range where scientific notation becomes the default? If I knew this range I could then force the format with the STR function to display the way I want. e.g. IF x>-001 and x<.001 then STR(X,"d.dddd")
    Either method would probably work for me.
    thanks,
    James
    Solved!
    Go to Solution.

    MyVar is a 2 dimensional pointer (Channel Group, Channel) to numeric channels that meet some criteria.
    change box size: I had to make the box 3 times the width to display the number correctly. It shows 1.27933333333333E-03*. I'm appending the "*" to show the field is calculated instead of unadultered from the .csv. Maybe the problem isn't that the number is small, but that it's infinitely repeating. The number is calculate from the values .001919 - abs(.001919)/3
    Left Justify: no difference from right justify.
    Autoadj: shows 1.28E-
    I'm making a column of channels on the report, that's why the comment text is being set multiple times.
    Humphreyy - thanks for your ideas and help.

Maybe you are looking for