Smartforms - Character field is too long

Hi
In my smartform I use a template, one of the fields is too long for the space it has in a template, and then it is shown too short. I want to show the whole field but in two lines, since there is no space in one line. Any suggestions in how I can trigger line feed.

Hi
If the cell of the template has more than 1 rows, the text should be written in two lines automatically.
Max

Similar Messages

  • P13n.ddl probs with UDB: field "value" too long to index

    We're trying to deploy the p13n.ddl on a UDB DB2 6.1.
    However, we encountered some problems:
    In UDB 6.1, an indexed column can be max 255 bytes long. So, the index
    WEBLOGIC_USER_ID_INDEX cannot be created, as the column "value" is one
    byte too long.
    CREATE TABLE WEBLOGIC_USER (userid int, property varchar(100), value
    varchar(256));
    CREATE INDEX WEBLOGIC_USER_ID_INDEX ON WEBLOGIC_USER (userid, property,
    value)
    How hard will omitting the "value" column from the index hit performance?
    All the columns in the table WEBLOGIC_USER has been indexed in one index.
    Was that done to prevent the DBMS from looking into the actual table at
    all (by looking only in the index)?
    Would it be possible to use the column as a varchar(255) or must it be
    256 chars wide? (Taking into consideration that the values at present are
    far from 256 chars.)
    Anders B. Jensen
    Consultant, Research & Development
    [email protected]
    LEC AS
    Denmark
    Remove the SPAMLESS to mail me.

    What you are trying to do shouldn't be a problem.
    There is no problems creating the weblogic_user as a varchar(255).
    I am not sure about omiting the "value" column and related performance
    issues, but I don't think it will be significant.
    "Anders B. Jensen" wrote:
    We're trying to deploy the p13n.ddl on a UDB DB2 6.1.
    However, we encountered some problems:
    In UDB 6.1, an indexed column can be max 255 bytes long. So, the index
    WEBLOGIC_USER_ID_INDEX cannot be created, as the column "value" is one
    byte too long.
    CREATE TABLE WEBLOGIC_USER (userid int, property varchar(100), value
    varchar(256));
    CREATE INDEX WEBLOGIC_USER_ID_INDEX ON WEBLOGIC_USER (userid, property,
    value)
    How hard will omitting the "value" column from the index hit performance?
    All the columns in the table WEBLOGIC_USER has been indexed in one index.
    Was that done to prevent the DBMS from looking into the actual table at
    all (by looking only in the index)?
    Would it be possible to use the column as a varchar(255) or must it be
    256 chars wide? (Taking into consideration that the values at present are
    far from 256 chars.)
    Anders B. Jensen
    Consultant, Research & Development
    [email protected]
    LEC AS
    Denmark
    Remove the SPAMLESS to mail me.

  • ServiceRequest field value too long, 2000 character max (SBL-EAI-13011)

    When I enter more than 2000 characters for a particular field - description, the update : "srequest.ServiceRequestUpdate(inset_input);"
    produces the following error:
    {System.Web.Services.Protocols.SoapException: Field 'Description' in the integration component 'Service Request' contains value 'detaidd...', which is longer than allowed length of 2000 characters.(SBL-EAI-13011)
       at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse
    Does anyone know why I am getting this 2000 character limit when I know this field should support 65k characters (65k is the max when using the ondemand website) ?
    Thanks Ahead Of Time                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

    Yeah you are correct. On OnDemand the length of this field is 16 K. This field is of Type CLOB in OnDemand
    But web services / analytics / reports doesn't support this field type and we have to restrict to length of 2000 K (This is a limitation)
    Till June that limitation was in place, I don't have the latest update. May be in some of recent patch they have corrected this.

  • Create_portlet_definition.sql probs with UDB: field "value" too long to index

    We're trying to deploy the create_portlet_definition.sql on a UDB DB2
    6.1.
    However, we encountered some problems:
    "COLUMN_ORDER" cannot be a part of the primary key because it can contain
    null values:
    CREATE TABLE "COLUMN_INFORMATION"
    ("PORTAL_NAME" VARCHAR(100) NOT NULL,
    "CATEGORY_NAME" VARCHAR(100) NOT NULL,
    "COLUMN_WIDTH" INT,
    "COLUMN_ORDER" INT,
    PRIMARY KEY(PORTAL_NAME, CATEGORY_NAME, COLUMN_ORDER));
    "GROUP_ID" cannot be a part of the primary key because it can contain
    null values:
    CREATE TABLE "GROUP_PERSONALIZATION"
    ("PORTAL_NAME" VARCHAR(100) NOT NULL,
    "CATEGORY_NAME" VARCHAR(100) NOT NULL,
    "PORTLET_NAME" VARCHAR(100) NOT NULL,
    "GROUP_ID" VARCHAR(100),
    "AVAILABLE" INT,
    "MANDATORY" INT,
    "EDITABLE" INT,
    "MOVEABLE" INT,
    "MINIMIZEABLE" INT,
    "MAXIMIZEABLE" INT,
    "FLOATABLE" INT,
    "VISIBLE" INT,
    "X" INT,
    "Y" INT,
    "MINIMIZED" INT,
    PRIMARY KEY(PORTAL_NAME, CATEGORY_NAME, PORTLET_NAME, GROUP_ID))
    Will these two columns ever contain a null value ?
    Anders B. Jensen
    Consultant, Research & Development
    [email protected]
    LEC AS
    Denmark
    Remove the SPAMLESS to mail me.

    any value that can contain null should not be a part of the primary key ever.
    I would just change the script so that the columns are not nullable - however,
    somebody from weblogic should confirm that this is ok.
    Filip
    In article <[email protected]>,
    [email protected] says...
    >
    We're trying to deploy the create_portlet_definition.sql on a UDB DB2
    6.1.
    However, we encountered some problems:
    "COLUMN_ORDER" cannot be a part of the primary key because it can contain
    null values:
    CREATE TABLE "COLUMN_INFORMATION"
    ("PORTAL_NAME" VARCHAR(100) NOT NULL,
    "CATEGORY_NAME" VARCHAR(100) NOT NULL,
    "COLUMN_WIDTH" INT,
    "COLUMN_ORDER" INT,
    PRIMARY KEY(PORTAL_NAME, CATEGORY_NAME, COLUMN_ORDER));
    "GROUP_ID" cannot be a part of the primary key because it can contain
    null values:
    CREATE TABLE "GROUP_PERSONALIZATION"
    ("PORTAL_NAME" VARCHAR(100) NOT NULL,
    "CATEGORY_NAME" VARCHAR(100) NOT NULL,
    "PORTLET_NAME" VARCHAR(100) NOT NULL,
    "GROUP_ID" VARCHAR(100),
    "AVAILABLE" INT,
    "MANDATORY" INT,
    "EDITABLE" INT,
    "MOVEABLE" INT,
    "MINIMIZEABLE" INT,
    "MAXIMIZEABLE" INT,
    "FLOATABLE" INT,
    "VISIBLE" INT,
    "X" INT,
    "Y" INT,
    "MINIMIZED" INT,
    PRIMARY KEY(PORTAL_NAME, CATEGORY_NAME, PORTLET_NAME, GROUP_ID))
    Will these two columns ever contain a null value ?
    Anders B. Jensen
    Consultant, Research & Development
    [email protected]
    LEC AS
    Denmark
    Remove the SPAMLESS to mail me.--
    Filip Hanik
    Software Architect
    XMarkstheSpot.com
    [email protected]

  • Unable to evaluate workflow rule - Value too long for field

    Need help with a workflow error for a record update before the record is saved. There are 3 calculations that would be done in a particular order - all on number fields. Each time, I am overwriting existing values. The individual numbers could have up to 6 decimal spaces. When I try to update one or more fields that contain the calculation, I get an error message saying that the system is unable to evaluate the workflow rule - value too long for field (zNum6).
    This same calculation is fine when a new record is entered and the calculation is done as a default field value.
    Any ideas?

    I actually had to use a ToChar function at the beginning of the calculation and #### to indicate the number of digits to make this work. Oracle Help Desk provided the answer - quickly.

  • FRM-40831: Value too long for field ROWID.

    Hi,
    I'm a newbie in forms and I've a problem when working with index organized tables, it post me this error:
    FRM-40831: Truncation occurred : Value too long for field ROWID.
    How can I solve this problem?
    Thanks for your help.
    Raúl

    This is a bug in Forms 9i (bug 2408210). The workaround is to:
    - change block property Key Mode to Updatable or Non-Updatable
    - set item property Promary Key to Yes for all items that correspond to an index column in the index-organized table

  • Custom Webdynpro text field is taking too long to accept input values

    Dear All,
                   I hvae created custom web dynpro for PO header fields in SRM. This WD contains a lot of fields. When i try to put cursor on a text field it is taking too long for the cursor to appear in that input text field. There is no problem with other fields which have search helps associated with them. This field with the problem is just a text field.
    Please help.
    thanks.

    Dear All,
                   I hvae created custom web dynpro for PO header fields in SRM. This WD contains a lot of fields. When i try to put cursor on a text field it is taking too long for the cursor to appear in that input text field. There is no problem with other fields which have search helps associated with them. This field with the problem is just a text field.
    Please help.
    thanks.

  • String beginning ":OLD.DIAL_..." is too long. maximum size is 239 character

    @C:\Y\trigger.sql DIM_DIAL_DIGIT ctva_ra TRG_DIM_DIAL_DIGIT1
    :OLD.DIAL_DIGIT_KEY,:OLD.BU_KEY,:OLD.NOP_ID_KEY,:OLD.SDCA_LOCATION_CODE,:OLD.TARGET_REGION_DESC,:OLD.TARGET_COUNTRY_CODE,:OLD.TARGET_COUNTRY_DESC,:OLD.LDCA_NAME,:OLD.SDCA_NAME,:OLD.LDCC_X_COORD,:OLD.LDCC_Y_COORD,:OLD.SDCC_X_COORD,:OLD.SDCC_Y_COORD,:OLD.POPULATION_DATE_TIME,:OLD.ISO_COUNTRY_CODE,:OLD.HOTLIST_IND,:OLD.BLACKLIST_IND,:OLD.UPDATE_DATE_TIME,:OLD.EVENT_TYPE_KEY,:OLD.PROVIDER_DESCRIPTION,:OLD.DM_IND,:OLD.DIAL_DIGIT_OPERATOR_TYPE,:OLD.CALL_DIRECTION_KEY,:OLD.DIAL_DIGIT_DESCRIPTION,:OLD.FORCE_RI_IND,:OLD.TEST_CALL_IND DIAL_DIGIT_KEY,BU_KEY,NOP_ID_KEY,SDCA_LOCATION_CODE,TARGET_REGION_DESC,TARGET_COUNTRY_CODE,TARGET_COUNTRY_DESC,LDCA_NAME,SDCA_NAME,LDCC_X_COORD,LDCC_Y_COORD,SDCC_X_COORD,SDCC_Y_COORD,POPULATION_DATE_TIME,ISO_COUNTRY_CODE,HOTLIST_IND,BLACKLIST_IND,UPDATE_DATE_TIME,EVENT_TYPE_KEY,PROVIDER_DESCRIPTION,DM_IND,DIAL_DIGIT_OPERATOR_TYPE,CALL_DIRECTION_KEY,DIAL_DIGIT_DESCRIPTION,FORCE_RI_IND,TEST_CALL_IND;
    when i am running this script it return's string beginning ":OLD.DIAL_..." is too long. maximum size is 239 characters.
    how will i overcome from this situation.
    i am passing parameter with .sql file

    string beginning ":OLD.DIAL_..." is too long. maximum size is 239 characte. Be patient my friend....

  • I am looking for a way to enter multiple dates into a field without the form becoming too long.

    I am looking for a way to enter multiple dates into a field without the form becoming too long.
    This will be used by an old school bookeeper who needs the form to fit on one page.
    Any ideas?

    Hi,
    If you don't need the field to provide a date picker, verify it's a date, or don't need to sort the dates in the table, you can just use a text area field, and have your form filler enter the dates comma separated.  Otherwise you'd have to add multiple fields.  However, you can lessen the space each field takes up veritically, by using the "Labels Left" option (in the toolbar).
    Thanks,
    Todd

  • Field SOMLRECI1-RECEIVER is too long to be included in the container?

    hi all,
                here i want to send an attachment with FM SO_DOCUMENT_SEND_API1 in the WorkFlow, so i create a BOR and try to add this FM to this BO as a method.
                While i try to generate this BO, it shows me such a message"Field SOMLRECI1-RECEIVER is too long to be included in the container".Could anyone tell me how to fix this issue, please?
    Thanks in advance.
    Desmond.

    How are you trying to call this method in the BOR method? Did you try to create a method using the function module as a template?
    I would recommend using the Send-Mail step type in the workflow instead of creating your own.

  • String beginning ":OLD.DIAL_..." is too long. maximum size is 239 characte

    @C:\Y\trigger.sql DIM_DIAL_DIGIT ctva_ra TRG_DIM_DIAL_DIGIT1
    :OLD.DIAL_DIGIT_KEY,:OLD.BU_KEY,:OLD.NOP_ID_KEY,:OLD.SDCA_LOCATION_CODE,:OLD.TARGET_REGION_DESC,:OLD.TARGET_COUNTRY_CODE,:OLD.TARGET_COUNTRY_DESC,:OLD.LDCA_NAME,:OLD.SDCA_NAME,:OLD.LDCC_X_COORD,:OLD.LDCC_Y_COORD,:OLD.SDCC_X_COORD,:OLD.SDCC_Y_COORD,:OLD.POPULATION_DATE_TIME,:OLD.ISO_COUNTRY_CODE,:OLD.HOTLIST_IND,:OLD.BLACKLIST_IND,:OLD.UPDATE_DATE_TIME,:OLD.EVENT_TYPE_KEY,:OLD.PROVIDER_DESCRIPTION,:OLD.DM_IND,:OLD.DIAL_DIGIT_OPERATOR_TYPE,:OLD.CALL_DIRECTION_KEY,:OLD.DIAL_DIGIT_DESCRIPTION,:OLD.FORCE_RI_IND,:OLD.TEST_CALL_IND DIAL_DIGIT_KEY,BU_KEY,NOP_ID_KEY,SDCA_LOCATION_CODE,TARGET_REGION_DESC,TARGET_COUNTRY_CODE,TARGET_COUNTRY_DESC,LDCA_NAME,SDCA_NAME,LDCC_X_COORD,LDCC_Y_COORD,SDCC_X_COORD,SDCC_Y_COORD,POPULATION_DATE_TIME,ISO_COUNTRY_CODE,HOTLIST_IND,BLACKLIST_IND,UPDATE_DATE_TIME,EVENT_TYPE_KEY,PROVIDER_DESCRIPTION,DM_IND,DIAL_DIGIT_OPERATOR_TYPE,CALL_DIRECTION_KEY,DIAL_DIGIT_DESCRIPTION,FORCE_RI_IND,TEST_CALL_IND;
    when i am running this script it return's string beginning ":OLD.DIAL_..." is too long. maximum size is 239 characters.
    how will i overcome from this situation.
    i am passing parameter with .sql file

    Looks like you are trying to save the history data (with :OLD values).
    If you are trying to generate a trigger at runtime, then you need a procedure which is able to loop through user_tab_columns for the given table and construct column strings for generation of triggers.
    Then you can use EXECUTE IMMEDIATE to create the trigger.
    Keep in mind that debugging such a procedure would be headache if you face any problems in creating the same.

  • PL-SQL-ORA-01704 - String literal too long

    Hello guyz;
    I am trying to store a value of over 4000 character long in a CLOB column and I got the error message that says "PL-SQL-ORA-01704 - String literal too long".
    What can I do to overcome this challenge?
    Thanking you for your usual support.

    sb92075 wrote:
    Problem Exists Between Keyboard And Chair
    We can't say what you are doing wrong since we don't know specifically what you actually do.Okay let me put it down this way.
    I have an application using SQL Server as d backend engine & now, the user wants to migrate to Oracle. I now wrote a mini-program to create a schema/user in oracle with the schema/database (being used by the app) from SQL server. I verified the structure very well & every is just fine. Now, data migration (from SQL Server to Oracle).
    I was able to move most tables data successfully without issue until I attempted to load a table which has a column (in SQL defined as text with over 4000 (var)chars/CLOB in Oracle). On moving a particular row to oracle db (after few rows have already been INSERTed into this particular table x), I got that err msg.
    After battling with that for a while, I concluded to make d (DataMigrator) app take just d first 4000 string - only if the value in that field value length > 4000. This worked perfectly without issue but you know the implication - Data lost.
    Do I need to switch something on/off in Oracle that expands the CLOB default maximum field size? Because I foresee this happening as soon as the application (that would now sit on Oracle) is now in use.
    If you still don't understand this, I don't know how beta 2 explain this!
    Edited by: aweklin on Mar 17, 2013 8:25 AM
    Edited by: aweklin on Mar 17, 2013 8:25 AM
    Edited by: aweklin on Mar 17, 2013 8:27 AM
    Edited by: aweklin on Mar 17, 2013 8:27 AM

  • ORA-09100 specified length too long for its datatype with Usage Tracking.

    Hello Everyone,
    I'm getting an (ORA-09100 specified length too long for its datatype) (a sample error is provided below) when viewing the "Long-Running Queries" from the default Usage Tracking Dashboard. I've isolated the problem to the logical column "Logical SQL" corresponding to the physical column "QUERY_TEXT" in the table S_NQ_ACCT. Everything else is working correctly. The logical column "Logical SQL" is configured as a VARCHAR of length 1024 and the physical column "QUERY_TEXT" is configured as a VARCHAR2 of length 1024 bytes in an Oracle 11g database. Both are the default configurations and were not changed.
    In the the table S_NQ_ACCT we do have record entries in the field "QUERY_TEXT" that are of length 1024 characters. I've tried various configuration such as increasing the the number of bytes or removing any special character but without any sucess. Currently, my only possible workaround is reducing the "Query_Text" data entries to roughly 700 characters. This makes the error go away. Additional point my character set to WE8ISO8859P15.
    - Any suggestions?
    - Has anyone else ever had this problem?
    - Is this potentially an issue with the ODBC drive? If so, why would ODBC not truncate the field length?
    - What is the maximum length supported by BI, ODBC?
    Thanks in advance for everyones help.
    Regards,
    FBELL
    *******************************Error Message**************************************************
    View Display Error
    Odbc driver returned an error (SQLExecDirectW).
    Error Details
    Error Codes: OPR4ONWY:U9IM8TAC:OI2DL65P
    State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 17001] Oracle Error code: 910, message: ORA-00910: specified length too long for its datatype at OCI call OCIStmtExecute: select distinct T38187.QUERY_TEXT as c1 from S_NQ_ACCT T38187 order by c1. [nQSError: 17011] SQL statement execution failed. (HY000)
    SQL Issued: SELECT Topic."Logical SQL" saw_0 FROM "Usage Tracking" ORDER BY saw_0
    *******************************************************************************************

    I beleieve I have found the issue for at least one report.
    We have views in our production environment that call materialized views on another database via db link. They are generated nightly to reduce load for day-old reporting purposes on the Production server.
    I have found that the report in question uses a view with PRODUCT_DESCRIPTION. In the remote database, this is a VARCHAR2(1995 Bytes) column. However, when we create a view in our Production environment that simply calls this materialized view, it moves the length to VARCHAR2(4000).
    The oddest thing is that the longest string stored in the MV for that column is 71 characters long.
    I may be missing something here.... But the view that Discoverer created on the APPS side also has a column length for the PRODUCT_DESCRIPTION column of VARCHAR2(4000) and running the report manually returns results less than that - is this a possible bug?

  • ORA-00972:identifier too long

    hi
    oracle up limitation ?
    create table aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(a char);
    Error
    ORA-00972:identifier too long
    or
    create table a (aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa char);
    Error
    ORA-00972:identifier too long
    Oracle can not support upto 32 characters table name and field name ?
    It is true?
    null

    If you do a search on the particular Oracle error, you get the following:
    ORA-00972 identifier is too long
    Cause: The name of a schema object exceeds 30 characters. Schema objects are tables, clusters, views, indexes, synonyms, tablespaces, and usernames.
    Action: Shorten the name to 30 characters or less.
    It would appear that there's a 30 character limit.
    Justin
    null

  • LOV - PL/SQL: numeric or value error: character string buffer too small

    I have a field set to 'text field with autocomplete' and now that the data that is used for the LOV has increased dramatically it returns the following error 'ORA-06502: PL/SQL: numeric or value error: character string buffer too small'. Through trial and error I determined that if I restricted the number of rows returned using rownum < nnn then it would work. I then determined that I could use the trim and substring functions and remove the rownum restriction and it would work. Below is the LOV query. I have seen a couple of other posts similar to my problem and one of them asked if there was a way to increase the buffer size, but it was never answered. Is there a way, such as a parameter setting, that I could increase the buffer size for LOVs?
    select distinct substr(trim(item_requested),1,50) d
    from consolidated_components
    order by 1
    Thank you.

    Hi Scott
    Thanks very much for jumping in here.
    No, I didn't use the wizard to create the page. It was a manual operation but to tell you the truth the page has been changed so many times as I was working on different functionality and appearance that anything could have happened. I ended up having to manually create row processing processes and delete other processes, creating and hiding buttons, changing the way I'm passing item values, etc. I realize regardless of what I do as a developer the software should be able to handle all changes through it's interface but I've been in this business long enough to be realistic.
    I also could have done something blatantly stupid as I continue to learn this product. For those of us not yet totally comfortable with all the web development technology, Javascript, AJAX, etc., but are asked to develop applications that work best using those technologies sometimes we make elementary blunders.
    Thanks very much for your help. It is indeed appreciated.
    -gary

Maybe you are looking for