Lpad .. correct use to right justify a char field?

Hi all,
I have a column that's a char type, and I'm trying to manipulate justification within it.
SQL> create table test (test char(14));
Table created.
SQL> insert into test values (' 001234567890');
1 row created.
SQL> select * from test;
TEST
001234567890
..I have no probs making it left justified using ltrim
SQL> update test set test=ltrim(test);
1 row updated.
SQL> select * from test;
TEST
001234567890
...but when I try to right justify using lpad I can't get it to work:
SQL> update test set test=lpad(test,14,' ');
1 row updated.
SQL> select * from test;
TEST
001234567890
..this should pad the column with blanks to make the string 14 in length right?
What am I doing wrong?
Thanks !
Adam

Hi, Adam,
A CHAR (14) column is always 14 characters long. If you insert a shorter string, it is automatically RPADded.
If LENGTH (test) = 14, then
lpad(test,14,' ')
simply returns test. So your UPDATE statement is equivalent to
update test set test= test;
Every row will get UPDATEd, but nothing will get changed.
To have the strings left-padded, use LPAD before INSERTing, or use UPDATE wtih LPAD and TRIM, like this:
UPDATE  test
SET     test = LPAD ( RTRIM (test)
                    , 14
                    );

Similar Messages

  • Cursor not right-justifying in Oracle Forms 11.1.1.6.0

    Hi All,
    A user notice during testing that 'cursor not right-justifying' in a field on a form. There were not such problem in the old forms enviroment 10.1.2.0.2 and clients running JInitiator 1.3.1.22. The new forms enviroment is Oracle weblogic 10.3.6, Oracle forms and report 11.1.1.6.0, using forms demo pack cursorpos.jar and demo90.jar, have try the 11g demo pack but still the same problem, any ideas?
    Thanks
    Ola

    A user notice during testing that 'cursor not right-justifying' in a field on a form.What exactly do you mean by "cursor not right-justifying"?
    You will find noticable differences between the way the Oracle Jinitiiator and Oracle (Sun) Java work. Remember, the Jinitiator was based on the Sun JRE/JDK 1.3 and Forms 11g will be using either Java 1.6.0 or 1.7.0.
    Craig...

  • Right-justified for amount in sap scipt

    Hi,
    good morning guys.
    I dev the sap script for cust.statment. every thing is fine.  i need to show the amounts like
    10000.00
      2000.90
        100.00
    20000.00
    but now iam getting the amt the differnt positions. i used the Right-justified &symbol(r)& but no use. and i used the &symbol(c)&
    no use. iam not getting the right way.
    my paragraph format  and tab postion *** like below
    first tab : 2.55 cm left ,
    second  : 5.10cm left,
    third: 6.50cm,left,
    fourth: 9.0cm,left,
    fivth:10.0cm,left,
    sixth:12.50 cm,DECIMAL
    seventh:13.50cm,DECIMLA
    eighth: 16.50cm, LEFT
    ninth: 18.00CM,DECIMLA
    plz can any one tell me how to over come thisprob
    regards
    chandu

    Hi Chandu,
    Please use Right tab position in your paragraph format. In your paragraph format all tab position are from left.
    Regards,
    Chandra K

  • Bad data returned using DSEE6.3: JDBC Data View to DB2 for CHAR fields

    I have created a JDBC dataview to a DB2 database using com.ibm.as400.access.AS400JDBCDriver. When using ldapsearch, the data returned is inconsistent with that which is on the database. The DB2 table has data types of CHAR, DECIMAL, and NUMERIC. For the Decimal and Numeric fields, I am not experiencing a problem. The data returned here maps exactly to that which is on the table. For CHAR fields, I get mixed results.
    When defining JDBC attributes in DSEE, I mapped the sql-syntax attribute accordingly for each corresponding attribute on the DB2 table. As a side note, I also configured each attribute so the ldap-syntax = ces (Case sensitive). Also, I could not find a way to define the length of the char for my JDBC attribute. I'm not sure if there's supposed to be a way that I just haven't figured out yet.
    For the CHAR fields, in some cases I get what's on the data source. In other cases, I don't. I've tried to find a pattern but have been unlucky so far. Many fields with length of just 1 come back ok, but a few of length 1 are incorrect. Some fields bigger then length 1 are ok, but the majority come back with garbage. Coincidently or not, it almost looks like a hash of some sort. I'm wondering if there is a character on the datasource that's causing problems with DSEE figuring out where the end of the string is. I'm using NetBeans to look at the database, but I don't have direct access to the DB2 database at this point to see the data directly.
    Has anyone experienced something simliar or have any suggestions as to further research of this problem?

    Upon further testing I have found that the problem mentioned exists only when using ldapsearch. When I used an ldap browser, the char fields looked as expected.

  • Using Right-justified and left zero-filled condition in message mapping of

    Hi,
    My Interface is outbound Interface.
    Suppose source field named 'MobNumber' is mapped with Target field named 'MobileNumber'.Condition is AS IS(Right-justified and left zero-filled).
    How should i do this mapping?
    Thanks,
    Sanghamitra

    Hi Sanghamitra,
         Similar question ahs been answered earlier in this thread
    Re: Message Mapping using Left justified, right blank/space filled
    just replace the filler variable by zero in my post
    One small request, if you think your questions are being answered correctly and properly, please kindly, if possible, close down the threads. This way forum members/users  who later look up for solutions to similar problem, they know for sure that the problem was finally solved, with the solutions provided in the thread.   
    regards
    Anupam
    Edited by: anupamsap on Aug 3, 2011 11:27 AM

  • FW: Caret Location Right Justified for LI when using HTMLEditorKit

    It appears that when using the HTMLEditorKit and inserting any sort of list
    item (ordered list or unordered list) into a view (while in edit mode), the
    caret is initially *---------| right justified with respect to the bullet
    image. If the identical html is loaded all at once however the caret is *-|
    left justified with respect to the bullet image. Is this a bug in
    HTMLEditorKit?

    Sure it is. In this special case IBM's JDK does a better job (at least under Linux).
    Generally I'm totally disappointed by the whole HTML package. I've been trying to implement a really primitive WYSIWIG-HTML-editor which understands <p>, <ul>, <h1> <b>, <i> and <a href>. It is a nightmare!
    - Dynamically modifying the document's structure (e.g., by making a <li> out of a <p>) works more or less, but you have absolutely no control over caret movement, and different JDK's make it differently!
    - The HTMLDocument inserts crude "extra-tags" (e.g., those <p-implied>'s. You never know exactly the structure of your document, and after a long debugging session you notice that the HTMLDocument was bluntly inserting yet another artificial element you did not specify. No docs at all what's going on.
    - It is nearly unbelievable how complicated so simple things like
    are internally modelled.
    - Frankly spoken: The whole document model sucks. Has to be harmonized with XML, DOM, JDOM, and all those nice new technologies where Java does a good job (unless you need a GUI...)
    If anybody has an idea to make it properly -> pls let me know
    thx
    Karl

  • HT2216 I am on OSX 10.7.5 and recently had to reinstall it due to 'mail' not working correctly.  That problem was resolved but now my I can't use the 'right click' function on the apple usb mouse.  Any clues?

    I am on OSX 10.7.5 and recently had to reinstall it due to 'mail' not working correctly.  That problem was resolved but now my I can't use the 'right click' function on the apple usb mouse.  I only have a previous version re-install disc as I bought the latest OSX off the app store.  Any help gratefully received?

    Hmmm, no, no drivers needed, now it sounds like a bad install... unless you might have some old Mouse software installed???
    If 10.7.0 or later...
    Bootup holding CMD+r, or the Option/alt key to boot from the Restore partition & use Disk Utility from there to Repair the Disk, then Repair Permissions.
    If that doesn't help Reinstall the OS.

  • Right-justify column name

    Hello Gurus
       I would like to right-justify the column heading. How can I do this? Specifically, this refers to the Quantity field in the Items assignment block in the Opportunities Overview screen.
    Regards,
    Sowmiya

    Try using LPAD like
    select lpad(object_name,30) from all_objects where rownum < 20;

  • Right Justify Numbered List

    In a very simple table, within Pages Layout - I want to list 10 numbered items and have the numbers be right justified. not the entire text, just the numbers. I do not find a way to do that. Thanks for any help.

    fruhulda wrote:
    I think OP is talking about a Table in Layout mode. If you have both text and number in the same cell you need to use tab BUT in a table you have to hold down the Alt key when using the Tab key, otherwise you only move to the next cell. In the Inspector you can change it to a right adjusted tab.
    Is that working for you?
    Here on my machine, if I put a decimal tab stop in the cell's ruler,
    the number aligns correctly when I insert a tab (alt + tab)
    but it returns to the left side when I leave the cell.
    It seems that the feature was designed for the old tables (those in iWork 1 and 2) but fails with the tables using the Numbers structure.
    Only the alignment buttons give a correct behavior (but the decimal characters are aligned only if the number of decimals is fixed and if the font used is a monospaced one. Boring, isn't it ?
    Yvan KOENIG (from FRANCE dimanche 14 juin 2009 19:06:04)

  • On the use of VARCHAR2 vs. CHAR

    I'm posting an e-mail thread that has been moving around in my organization, whith guidance from an Oracle representative.
    The basic issue concerns the use of CHAR vs. VARCHAR2 when defining a table in Oracle.
    I would like to get some comments from the community at large.
    1. Business semantics should be represented in every aspect of a database, application, and design as far as I am concerned. Noteably, if the business rule at a corporate entity is clearly stated that when using Oracle the use of CHAR should be limited to those attribute implementations which have the following characteristics; a) The attribute may not be null, b) The attribute must have a character in each of the declared positions.
    2. When the Visual Basic application began writing data to the CHAR columns in your application someone should have had a discussion with the developer to find out why this was happening. If the business semantics changed then the logical implemention of the business semantics should have changed as well. That the two were disconnected is not a problem with the CHAR type, it is a problem with the designer or the developer. The bottom line on this instance is that the column should have been defined as a VARCHAR2 data type since the business semantics no longer complied with the criteria set forth in the previous paragraph.
    3. I think Oracle trys to load as much of the data from a table or index into shared memory, in this case the database block buffers, as it can in order to facilitate query operations. If Oracle has enough memory and can load a table or index into memory, it will do so. At the same time the database engine will move previously cached data out of memory to accommodate the new requirement.
    -----Original Message-----
    Thank you for the detail information on CHAR and VARCHAR2. It got me thinking with a DBA hat. I worked as a DBA before and I did use the CHAR type and I will share my experience/thought on CHAR.
    I don't like to use the char type like Tom has advised because Oracle does not check to see if the value being inserted fills up the column or not which can lead to a problem. And there is no performance gain or save space in Oracle.
    I worked as a DBA before, I used char type on the "must fill/always filled" column (pre DMDC). The application was written in VB with Oracle back end. At some point, VB started inserting values that are short of the column width and created a minor problem (it was supposed to be filled column). The problem was quickly identified and fixed, but it caused an issue.
    I realize that I don’t want to define it as a "must fill/always filled" column if you can't enforce it by simply defining the char data type on a table and prevent possible issue in the future.
    For a manager, in order to use the char properly, you have to hire client developers with Oracle experience or provide a basic Oracle training in order to avoid the problem I mentioned above in order to use the char type correctly.
    I think you, Tom and I are saying the same thing really. Only difference is that Tom and I can not think of a good reason why anyone would like to indicate the business semantics using column type on the database, when it can lead to more work/issues.
    In regards to wasted 25 million byes, why would Oracle load the table with 25 million rows? Shouldn't it use an index? Don't you have a serious problem if Oracle is loading table with the 25 million rows?
    Just my two cents... : )
    -----Original Message-----
    May I beg to differ?
    CHAR plays a vital role in the intuitive interpretation of a database schema. If designed correctly, the use of CHAR tells anyone who is in the know that this is a must fill column. Thus if a column is defined as CHAR(3) everyone should know that the column will always contain three characters. Defining the column as VARCHAR2(3) does not tell you anything about the data other than that the column may contain 0-3 characters.
    Also, If a column is defined as CHAR the column should always be populated. One of the nice features of VARCHAR2 is that if the column is defined at the end of a table, there is no storage overhead until that column is actually populated. Thus if you have a table that has an identifier that is nine characters in length and will always be populated with nine characters, an attribute which describes the type of identifier which is contained in the first column and which must always be populated and is a must fill attribute, and another column which is descriptive and may vary in length or not be populated at time of insert; the following definition does not express the business semantics of the entity:
    COL_CD VARCHAR2(9)
    COL_TYP_TXT VARCHAR2(26)
    COL_TYP_CD VARCHAR2(2)
    The above definition also does not take advantage of inherent storage features of Oracle; notably there is a wasted place holder between COL_CD and COL_TYP_TXT and between COL_TYP_TXT and COL_TYP_CD. The next definition does take advantage of the storage features but does not represent the business semantics of the entity:
    COL_CD VARCHAR2(9)
    COL_TYP_CD VARCHAR2(2)
    COL_TYP_TXT VARCHAR2(26)
    The above definition does not waste space storing a place holder between COL_TYP_CD and COL_TYP_TXT if the COL_TYP_TXT may be null. The column separator will only be used when the column contains data. The below definition satisfies both the storage and business semantics issues:
    COL_CD CHAR(9)
    COL_TYP_CD CHAR(2)
    COL_TYP_TXT VARCHAR2(26)
    This may seem pedantic in nature until you consider the situation where there are 25 million rows in the table represented by the above entity. If each row has a NULL COL_TYP_TXT value then the first example wasted 25 million bytes of storage and 25 million bytes of memory if the full table is loaded into memory. This is an issue which cannot be ignored in high volume databases.
    You may wish to know why it is important to define a must fill/always fill column as a CHAR to express the business semantics of an attribute. I can't give a definitive answer to that other than to say that it is just good database manners.
    So please, continue to use CHAR when the shoe fits. Don't throw something away that has use just because it is not popular or in the mode.
    Also, if I am mistaken in any of the above, please feel free to educate me.
    Thanks.
    -----Original Message-----
    Subject: RE: Oracle on the use of VARCHAR2 vs. CHAR
    Ignore if you already got this. This is just FYI.
    -----Original Message-----
    Below is a detailed answer to your VARCHAR2 or CHAR questions from our Database expert Tom Kyte. The short answer is VARCHAR2 is what you want to use. If you have any questions or want to discuss this in more detail let me know.
    A CHAR datatype and VARCHAR2 datatype are stored identically (eg: the word 'WORD' stored in a CHAR(4) and a varchar2(4) consume exactly the same amount of space on disk, both have leading byte counts).
    The difference between a CHAR and a VARCHAR is that a CHAR(n) will ALWAYS be N bytes long, it will be blank padded upon insert to ensure this. A varchar2(n) on the other hand will be 1 to N bytes long, it will NOT be blank padded.
    Using a CHAR on a varying width field can be a pain due to the search semantics of CHAR.
    Consider the following examples:
    ops$tkyte@8i> create table t ( x char(10) ); Table created.
    ops$tkyte@8i> insert into t values ( 'Hello' );
    1 row created.
    ops$tkyte@8i> select * from t where x = 'Hello';
    X
    Hello
    ops$tkyte@8i> variable y varchar2(25)
    ops$tkyte@8i> exec :y := 'Hello'
    PL/SQL procedure successfully completed.
    ops$tkyte@8i> select * from t where x = :y; no rows selected
    ops$tkyte@8i> select * from t where x = rpad(:y,10);
    X
    Hello
    Notice how when doing the search with a varchar2 variable (almost every tool in the world uses this type), we have to rpad() it to get a hit.
    If the field is in fact ALWAYS 10 bytes long, using a CHAR will not hurt -- HOWEVER, it will not help either.
    The only time I personally use a CHAR type is for CHAR(1). And that is only because its faster to type char(1) then varchar2(1) -- it offers no advantages.
    If you just use varchar2 everywhere, no problem
    My advice is, has been, will be very loudly stated as:
    IGNORE THE EXISTENCE OF CHAR.
    period. If you never use char, you never compare char to varchar2, problem solved.
    And if you use char and compare a char(n) to a char(m) they will never compare either.
    Just say NO TO CHAR.
    **************************************************

    Hi,
    >>A CHAR datatype and VARCHAR2 datatype are stored identically (eg: the word 'WORD' stored in a CHAR(4) and a varchar2(4) consume exactly the same amount of space on disk, both have leading byte counts).
    Ok, but on the other hands:
    SGMS@ORACLE10> create table x (name char(10), name2 varchar2(10));
    Table created.
    SGMS@ORACLE10> insert into  x values ('hello','hello');
    1 row created.
    SGMS@ORACLE10> commit;
    Commit complete.
    SGMS@ORACLE10> select vsize(name),vsize(name2) from x;
    VSIZE(NAME) VSIZE(NAME2)
             10            5
    SGMS@ORACLE10> select dump(name),dump(name2) from x;
    DUMP(NAME)                                         DUMP(NAME2)
    Typ=96 Len=10: 104,101,108,108,111,32,32,32,32,32  Typ=1 Len=5: 104,101,108,108,111Cheers

  • Using the right apple ID and password I can't sign into iMassage? Why

    Using the right apple ID and password with wi-fi I can't sign into iMassage. Why?

    Did you purchase Apple Care? If you did, you still have access to Apple Support.  If not, go to your Apple Store and let them help you get it set up correctly.  I'm sure it's something simple we're missing.  Good Luck. 
    Do remember one thing.  iMessage on iPad only works with other iOS devices.  This means you can only text to people who:
    1.  Have an iPhone, iPad, or iPod Touch
    2.  And they have upgraded to iOS 5 or higher

  • Query don't use the right index when using bind variables

    Hi people !
    I need some help because I have an issue with a query that don t use the right Indexes as it should
    First of all, I have mainly three tables :
    ORDER : Table that contains description for each Order (approximately 1 000 000 Records)
    ORDER_MVTS : Table that contains the tasks made (called movements) to set up each Orders
    with quantity of packages prepared for each product (approximately 10 000 000 Records)
    PRODUCT : Tables that contains the products (approximately 50 000 Records)
    When I launch the query with hard coded values, it brings back response very fast
    because it uses the right index (ORDER_DHR_VALID) which represent the date and hour of the order
    (with format 'DD/MM/YYYY HH24:MI:SS'). The selectivity for this index is good.
    NB 1: I have to use the trick " >= Trunc(date) and < trunc(date) +1 " to filter on a simple date because
    the index contains hour and minutes (I know it wasn't probably a bright idea at conception time).
    NB 2: The index on ORDER_MVTS.PRODUCT_CODE is'nt discriminating enough because there is'nt enough different products.
    It's the same for index on CUSTOMER_CODE and on MVT_TYPE so only the index on ORDER.DHR_VALID is good.
    Here is the correct explain plan when I execute the query with hard coded values :
    SELECT SUM(ORDER_MVTS.NB_PACKAGE)
    FROM ORDER_MVTS, PRODUCT, ORDER
    WHERE ORDER.DHR_VALID >= TRUNC(to_date('14/11/2008 10:04:56','DD/MM/YYYY HH24:MI:SS'))
    AND ORDER.DHR_VALID < TRUNC(to_date('14/11/2008 10:04:56','DD/MM/YYYY HH24:MI:SS')) + 1
    AND ORDER_MVTS.MVT_TYPE = 'DELIVERY'
    AND PRODUCT.CODE = ORDER_MVTS.PRODUCT_CODE
    AND ORDER_MVTS.ORDER_CODE = ORDER.CODE
    AND ORDER.CUSTOMER_CODE = 'ADIDAS'
    AND PRODUCT.CODE = 1234
    Rows Row Source Operation
    1 SORT AGGREGATE
    2 NESTED LOOPS
    4 NESTED LOOPS
    2 INDEX UNIQUE SCAN (object id 378548) --> PRODUCT_PK
    4 TABLE ACCESS BY INDEX ROWID ORDER
    777 INDEX RANGE SCAN (object id 378119) --> ORDER_DHR_VALID
    2 TABLE ACCESS BY INDEX ROWID ORDER_MVTS
    30 INDEX RANGE SCAN (object id 377784) --> ORDER_MVTS_ORDER_FK
    Now the problem is when the query is used in a Cursor with bind variables.
    It seems like Oracle don't use index on ORDER.DHR_VALID because he can't figure out that he have
    to actually filter on a short period of time (only one day).
    So Oracle uses the index on ORDER_MVTS.PRODUCT_CODE which is'nt a bright idea (it takes 10 secondes instead of just one)
    Here is the bad explain plan :
    Rows Row Source Operation
    1 SORT AGGREGATE
    2 NESTED LOOPS
    722 NESTED LOOPS
    2 INDEX UNIQUE SCAN (object id 378548) --> PRODUCT_PK
    722 TABLE ACCESS BY INDEX ROWID ORDER_MVTS
    1790 INDEX RANGE SCAN (object id 377777) --> ORDER_MVTS_PRODUCT_FK
    2 TABLE ACCESS BY INDEX ROWID ORDER
    1442 INDEX UNIQUE SCAN (object id 378439) --> ORDER_PK
    Now I have found two solutions to this problem :
    1) using a Hint to force the use of index on ORDER.DHR_VALID (with /*+ INDEX(ORDER ORDER_DHR_VALID) */ )
    2) Using Dynamic SQL and keeping the date hard coded (but not the other values except mvt_type)
    For example :
    QUERY :=
    'SELECT SUM(ORDER_MVTS.NB_PACKAGE)
    FROM ORDER_MVTS, PRODUCT, ORDER
    WHERE ORDER.DHR_VALID >= TRUNC(TO_DATE('''||To_char(P_DTE_VAL,'DD/MM/YYYY')||''',''DD/MM/YYYY'')) '||
    AND ORDER.DHR_VALID < TRUNC(TO_DATE('''||To_char(P_DTE_VAL,'DD/MM/YYYY')||''',''DD/MM/YYYY'')) + 1 '||
    AND ORDER_MVTS.MVT_TYPE = 'DELIVERY'
    AND PRODUCT.CODE = ORDER_MVTS.PRODUCT_CODE
    AND ORDER_MVTS.ORDER_CODE = ORDER.CODE
    AND ORDER.CUSTOMER_CODE = :CUSTOMER
    AND PRODUCT.CODE = :CODE ';
    These two solutions work but Number 1 is bad in theory because it uses a Hint
    and Number 2 may be difficult to code.
    So my question is : Does someone knows another solution to force the use of index ORDER_DHR_VALID that can be simple and reliable.
    Thank you very much for support
    Edited by: remaï on Apr 1, 2009 4:08 PM

    What version of oracle you have? CBO work is different in 9i and 10g.
    Usually cost based optimizer do not want to use index for >< condition with binding variables because optimizer can not use statistic to determine selectivity, and by default selectivity of <> operators is low.
    (As I remember '>' selectivity by default is 5%, you have two conditions > and <, therefore resulting selectivity will be 0.05*0.05=0.0025 as two independent events, but selectivity of other conditions
    ORDER_MVTS.MVT_TYPE = 'DELIVERY' or ORDER.CUSTOMER_CODE = 'ADIDAS' looks much better for CBO)
    The best solution I see is do not use binding variables. Actually your query looks as searching query, which executes not so often, therefore you will not have perfomance win along of skipping execution plan creation.
    Edited by: JustasVred on Apr 1, 2009 10:10 AM

  • How to Right Justify text on Ipod

    My ipod has been through some wear and tear, long story short, the screen is "cracked" so to speak down the middle and from the middle of the screen to the left side i cannot see anything. I'm trying to figure out how to right justify all of the text so that i can actually use my ipod and search songs

    You can't change the layout of any part of the iPod OS. Sorry. You might want to consider getting the screen replaced. There are lots of third party repair outfits that charge less than Apple to so the job.

  • Sort options right justified in list view

    New to Maverick's, but I can't get my finder window to "stick" with the layout of the "sort options". My biggest beef is that I have the "Name" sort far left followed by "Date modified", etc.. yet every day in every new finder window, the 2nd sort jumps to right justified. I want this sort option to stick to the left alongside name. I use large monitors and scrolling over everytime to drag the sort modifier to the left is frustrating. Is there a solution?

    My guess would be the Images folder (Pictures in English) is designed to have the special, contextual grouping types.
    I don't know why they couldn't make them available in the dropdown menu, also, but they're not.
    I did a little testing and found if I called it Pictures unsorted, the options were available, but if I called the folder unsorted Pictures, they weren't.
    Try naming the folder starting with Images
    Edit: If I select the dimension and resolution column headers in the folder, then change the name of the folder, the columns are retained.

  • Tab delimited and Right justified fields

    Hi
    My requirement is to produce an output file where the line items consists of 5 fields of variable lengths and all of them are tab delimited and right justified at the same time
    for eg.
    ABC       123456ghtje  4567.45678   67.45678  pqr
    where all the values in the first field 'ABC' and 2nd field '123456ghtje' are right justified and are tab delimited and asme is the case for '4567.45678' , '67.45678' and 'pqr'
    they are all separated from each other by a tab but are not fixed lengths
    How can i achieve that ? i am using File Receiver Adapter ??
    Can it be done without Adapter Module ?
    Thanks
    Dev
    Edited by: sd on Feb 22, 2010 2:25 PM
    Edited by: sd on Feb 22, 2010 2:26 PM

    > they are all separated from each other by a tab but are not fixed lengths
    When thay are not fixed length fields, why do you have to worry about left or right justification? In delimetted files, you would only have the delimitter between the fields. You do not need to fill spaces for justifying them.
    VJ

Maybe you are looking for