Compile Form against UTF8 Database

Hello,
Is it necessary to compile a Form against UTF8 Database to run it against UTF8 Database?
I'm on Forms 10.1.2.0.2 and Database 10.2.0.3.
Database Parameters are:
NLS_CHARSET=UTF8
NLS_LENGTH_SEMANTICS=CHAR
Can I compile a Form against WE8MSWIN1252 Database (NLS_LENGTH_SEMANTICS Parameter of the DB is also set to CHAR and when compiling the form the environment variable is also set to CHAR), and run the form against UTF8 Database (including the needed .env file in the formsweb.cfg), or do I have to set NLS_LANG and recompile the form against UTF8 database?
thx and regards,
Christian

Well I thought that I have to ask support...But I hoped someone had some experiences with that.
But here are some troubles I had with UTF8, maybe it helps someone, if not it's a nice type-in training ;-):
We had some very strange behaviours regarding forms with UTF8 databases, so the first believe was, that I have to generate against UTF8 database.
Well - the bad thing was the NLS_LENGTH_SEMANTICS parameter, which we set to CHAR for UTF8, and also for WE8, for the reason that a VARCHAR2(255) can really contain 255 chars, and not maybe 255/3 chars...
As the strange "Signature of Package has been changed" error which occured in UTF8 also occured in WE8, I did some researches.
The problem occured, when I had a record type (no %rowtype, no %type) declared in a database package spec, instanciated in forms, and given as a parameter to another stored procedure.
scenario:
forms compiled with NLS_LENGTH_SEMANTICS=CHAR, the package created and compiled with NLS_LENGTH_SEMANTICS=CHAR; => correct behaviour.
now in sqlplus:
alter session set NLS_LENGTH_SEMANTICS=BYTE;
alter package <recordpackage> compile;
and run the form again => ora-4062.
but as said: after some time this behaviour also happened in WE8.... Charset, and at the moment I didn't have any other troubles...hm...I'll have to do some checks.
but thanks for your response
regards

Similar Messages

PDE-PDS001 cannot compile pu against 10g database

Error occurs when compiling form/library 10as/10g db
database version 10.1.0.2
forms version 9.0.4.0.19 also forms6i patch15
library that can be succesfully compiled against ver 8.1.7.3 and 9.2.0.3 cannot be compiled against 10g database
PDE-PDS001 Could not resolve reference to <Unknown Program Unit> while loading Procedure Body
I've got a procedure in a library which reference database package record type
error 905 object package <name> is invalid - but Database package is valid !
Searching metalink I came across similar issues with earlier versions of database/tool combinations - Has this error surfaced again ?
Database package specification includes (in additions to procs/functions) the following:
TYPE suppress_tabtype IS TABLE OF VARCHAR2 (15) INDEX BY BINARY_INTEGER;
-- public program units
TYPE message_rectype IS RECORD
( msg_code VARCHAR2(15)
, severity VARCHAR2(1)
, severity_desc VARCHAR2(100) -- Translated description of severity
, suppr_wrng_ind VARCHAR2(1)
, suppr_always_ind VARCHAR2(1)
, logging_ind VARCHAR2(1)
, msg_text VARCHAR2(2000)
, help_text VARCHAR2(2000)
, lang_code VARCHAR2(3)
, raise_error BOOLEAN
, message_found BOOLEAN);
TYPE message_tabtype IS TABLE OF message_rectype INDEX BY BINARY_INTEGER;
Does a patch exist ?
TIA
Pete

Hi Pete
I encountered the same problem in Oracle Forms 10g (9.0.4.0.19) with an Oracle 10g database. My error was caused by default values in the form of a function call in one of the procedures functions
f.e.
package my_package
function my_function
( par1 varchar2
, par2 varchar2 default my_function_in_another_package
) return varchar2;
end;
Remove the default value in the function parameter par2 and everything works fine
Hope this helps,
Matthieu

Problem in running a 6i-form against 10g-Database

Hi gentlemen, I'm developing my application with Database 10g and Developer-6i at front end. when I compile a file (which was formarly created with Dev-6i but Database 8.3(personal edition)at the back end) it gives the following error:
Compiling PRE-INSERT trigger on PURINV_MAS data block...
Compilation error on PRE-INSERT trigger on PURINV_MAS data block:
PL/SQL ERROR 0 at line 0, column 0
ORA-00600: internal error code, arguments: [17069], [77299844], [], [], [], [], [], []
Compiling WHEN-LIST-CHANGED trigger on UNIT_NAME item in PURINV_MAS data block...
Compilation error on WHEN-LIST-CHANGED trigger on UNIT_NAME item in PURINV_MAS data block:
PL/SQL ERROR 0 at line 0, column 0
ORA-00600: internal error code, arguments: [17069], [77299844], [], [], [], [], [], []
Compilation errors have occurred.
however if I run this file again with Db8x at back-end,it compiles n runs correctly without any error. Plzzz can u tell me a solution for this? thanx.

With 10g database, minimum required patch is patch 16 (patch 17 is last Forms 6i patch).
Regards,
Zlatko Sirotic

Compiling against developer database, running against production database??

Hello :-)
In our company we have a developer- , a test- and a production database, like most of us, I think... :-)
In former times it was usual to compile forms against the database, that they are running against. But nowadays this is because of new security rules very difficult. Developers have all rights on the developer database, a few on test and nearly none on the production database and even our DBA is (officially) not allowed to use/know the sys password.
The developer and the production database are very similar (both 10g Enterprise Edition Release 10.2.0.3.0 - 64bit, Linux), but not totally equal. Of course there are differences in database objects, because it's the developer database, there could be differences in installed patches, and the production database consists of 4 Clusters, the developer database not.
Is it enough to compile the forms (6i and also 10g) against the developer database and run the compiled forms against the production database or should we compile the forms, that go in production, strictly against the production database, which is a bit difficult because of our security rules???
Regards,
Udo

Hello, Francois!
Thanks for your answer, but that was not exactly what I meant...
What you describe is, how it should be :-)
We develop, deliver the forms and scripts and "someone" compiles them against the production database.
But our problem is that it would be a lot of "paperwork"(?) each time(!) to get the authorization to get the required rights on the production database to compile all objects.
We have no "production team" that has all these rights and are not allowed to do so...
So I just want to have your experiences, if it is enough to compile against the developer database???
I have made the experience that probably 98-99% works fine, but sometimes there are strange things happening (like not passing variables from one form to another, when a form is compiled against the developer database and the attached library for example is compiled against the production database)...
Regards,
Udo

Running a reports against different databases

I have written a report that uses a ref cur in a database package to derive the main query. I've compiled the report and it runs fine.
The problem is when I try to run it against a database other than the one it was compiled against (i.e. compile against DEV DB, test against TEST DB, finally migrate to PROD DB). Each of these databases are identical in terms of their objects but if I run the report against an environment it wasn't compiled against I get the following messages:
REP-1437 Run time error in the PL/SQL development environment (DE).
PDE-PSD001 Could not resolve reference to <Unknown Program Unit> while loading <unknown> <unknown>
I noticed initially that the report and the database package had the same name, I though this may be confusing things so I renamed the stored proc but I still get the same results.
I can get around the problem by either re-compiling it against each database or by getting the form to call the .rdf (rather than the .rep) so it is recompiled as and when required but this doesn't seem right.
Anyone have any ideas?

Hi Steve,
You can try using the RECURSIVE_LOAD parameter. By default, it is set to YES. If you are running with the .rep, set it to NO on your command line. What this means, is that it will not try to recompile the plsql in your report.
Hope that helps,
Toby

Forms 6i Against 9i UTF8 database with NLS_LENGTH_SEMANTICS = CHAR

Hi all,
I have a 9.2.0.4 database which was created with a character set of UTF8.
I want to start storing multibyte characters in this database so I changed the init.ora parameter NLS_LENGTH_SEMANTICS to CHAR and restarted.
I then installed my application into the database and all the definitions have correctly been created using CHAR length semantics.
The client to this application is Forms 6i but I am having serious problems compiling it against the application schema.
When I open a pll library and try to compile I get Error 201 for every %type variable declaration and also for server based packages.
I am definitely connected and to the correct schema where the objects all exist.
I have another application schema - identical except that it was created before I made the change to NLS_LENGTH_SEMANTICS so it uses BYTE. When I compile the same library connected to this schema there are no problems.
Also, if I try to connect to the CHAR schema using Forms (i.e. 8.0.6) SQL*Plus it crashes with a Windows Application Error. If I connect with a 9.2.0.1 SQL*Plus its fine.
My question is should it be possible to compile a 6i Form against a UTF8 database with CHAR NLS length semantics at all? Have I done something wrong or am I barking up the wrong tree? Has anyone else tried this?
Many thanks in advance,
Kevin.

Hi,
Thanks for the responses but I don't think you're quite right. Forms 6i should indeed work with Unicode as a database character set as long as it is UTF8 rather than AL32UTF8. This can be seen in various Metalink documents and also in the Release 6i Guidelines for Building Applications here (section 4.1.5):
http://download-west.oracle.com/otn_hosted_doc/forms/forms/A73073_01.pdf
The problems started when I changed NLS_LENGTH_SEMANTICS to CHAR. Its understandable if Forms 6i does not recognise this setting as it pre-dates it but I wanted to confirm this.
We want to migrate our existing application to work with multibyte characters. Unfortunately there are table columns, PL/SQL variables etc. that are too small when defined as a length in bytes.
I am looking for the least impact method to rectify this. On the server I can use NLS_LENGTH_SEMANTICS but if I can't get Forms to work with it then I may need to rethink.
I realise that using Forms 9i or 10g would support the parameter but it is not possible to upgrade at the moment.
Has anyone any other suggestions or methods for migrating an application to using multibyte characters?
Thanks again,
Kevin.

FORMS 6i and referenced forms in the database and compilation

Hello everybody,
I must work on an existing FORMS 6i APPLICATION.
I'm using FORMS 6i patch 18 on an ORACLE DATABASE 10g.
When I open a form I've got the message 'to retrieve reference objects, you must connect to the database' ( I think subclassed objects ), I do it and I got the error 'Failed to load objects ....'
In fact, I realize that the form I have to modify contains some objects referenced in some ( 3 in fact ) fmb source files, after searching on the web I have to 'insert' these 3 forms in the database : I have done it.
Everything is OK now : no more error when opening the form, I modify it and compile it on my testing environnment.
My question is : Do I have to "insert" these 3 source fmb forms into production in order to make my compiled fmx executable ??
Indeed, the only way to insert a form into database is to have the developper 6i database tables in the database, but in production I think it does not matter, do you ?
thanks a lot.
Romeo Georgievski.

You only need the referenced objects when
- changing the form in the Builder
- generating/compiling the form
When generating/compiling Forms Builder or Forms Compiler are resolving the references against the objects stored in the database.
They are now part of the runtime form (fmx file).
Note:
Storing objects into the database is desupported/depricated after Forms 6i (6.0.8).

Cannot run a UNICODE kernel against a non-UTF8 database

Hi,
I am trying to install SAP ECC 6.0 SR2 . am using windows 2003 server oracle 10g db.
please help me how to resolve this...
sapparam: sapargv( argc, argv) has not been called.
sapparam(1c): No Profile used.
sapparam: SAPSYSTEMNAME neither in Profile nor in Commandline
D:\usr\sap\DEV\SYS\exe\uc\NTI386\R3load.exe: START OF LOG: 20100717144107
D:\usr\sap\DEV\SYS\exe\uc\NTI386\R3load.exe: sccsid @(#) $Id: //bas/700_REL/src/R3ld/R3load/R3ldmain.c#13 $ SAP
D:\usr\sap\DEV\SYS\exe\uc\NTI386\R3load.exe: version R7.00/V1.4 [UNICODE]
Compiled Jul 17 2007 01:28:45
D:\usr\sap\DEV\SYS\exe\uc\NTI386\R3load.exe -testconnect
DbSl Trace: ORA-1403 when accessing table SAPUSER
DbSl Trace: Cannot run a UNICODE kernel against a non-UTF8 database (charset = AL32UTF8)
(DB) ERROR: db_connect rc = 256
DbSl Trace: Default conn.: already connected to DEV
(DB) ERROR: DbSlErrorMsg rc = 29
D:\usr\sap\DEV\SYS\exe\uc\NTI386\R3load.exe: job finished with 1 error(s)
D:\usr\sap\DEV\SYS\exe\uc\NTI386\R3load.exe: END OF LOG: 20100717144108

Reinstallae the server .problem solved thanks to 3everyone

Database link error when compiling forms 6.0 and forms 6i.

Dear sirs,
We have a database link between two databases of the same version oracle 8.0.5.
Recently we have upgraded one of our databases to version 9.2.0.1 (the database where the database link was originally created ) and now we are having problems when compiling forms that have PL/SQL blocks using the database link.
The error message received when compiling the form is the following:
ORA-02068: Following severe error from dbproduc.world
ORA-00600: Internal error code, arguments: [No conversion op],[],[],[],[],[],[],[]
The forms did not present this error before, it began when we made the upgrade.
Is this a FORMS 6.0 problem ?
Is this an ORACLE 8.0.5 problem ?
Is this an ORACLE 9.2.0.1 problem ?
Can you please give me some advice to solve this problem ?
Thanks in advance

As I see, when you use a non-oracle database the tables don`t appear, you must create the realation with the table manually, on the properties

Forms 6i against 11g database server - certification plan ? [ANSWERED]

Oracle folks, any plan to certify Forms 6i with a patchset against the upcoming version of the database server ? (before 6i ext. support ends end of Jan. 08)
We ported our Forms 6i apps to 10gR2 already but we want to support the 6i version of the c/s application against 11g database server.
thanx

;) this is what I meant. BTW, this is not just a user forum but it is also monitored by Oracle employees, Forms product managers, etc. So, it is one of the "official" resources if we need an answer from Oracle Corp. This apply to any OTN forum. If you look at Metalink, folks are posting there and on OTN hoping to hear official answers. This is not an issue that you can create an SR. This particular matter was discussed on ODTUG and with OPN, and it was OPN related Oracle Employee's suggestion to post it on OTN forms forum. Thanx anyway.

Forms 4.5 against 10g database?

Can anyone tell me the latest version of the Oracle database that Forms 4.5 will work against? From what I've read v8.1.6 is the latest version that Forms is certified to work against - correct? But is there any reason why it shouldn't work against 10g?

Hi, I have tried this way back when, and it works fine against 10g. Couple of things to remember: under the forms 4.5 it installs an earlier version of Oracle Net, therefore the tnsnames.ora file under the formshome/network/admin is not compatible with 9i and higher. Create a directory like /var/opt/oracle (or on windows something similar) then set your TNS_ADMIN variable to point to that directory. Then, binary ftp the tnsnames.ora and sqlnet.ora from your 10g database server home/network/admin to /var/opt/oracle directory. Then you should be able to connect to the 10g db server from your forms. There were some known issues with forms 4.5 and even 6i against the very first version of 9i (database was not releasing locks issued by forms), but those problems were fixed with 10g release 1, so you should be ok. But remember, because this is not a certified combination (by Oracle), if you have any major problem with your form/db combo, you will be on your own. Make sure your forms are using the latest patchset for 4.5 version. BTW, only certified version of forms against 10g is Forms 6i with patchset 17 or higher (18).

Deploy form, question about database object or connection parameters

When form to be deployed to the dev/test/production environment, should it be compiled with that specific database connection username, password and sid? Another words, when I compile the database objects created for the compile is embedded in the .fmx file?
thanks for help

You won't need to compile your forms if the passwords of the target schema differs. It also doesn't matter on what platform/architecture the database server runs on. However it would matter how you created your schema objects. And of course it will matter if the platform your forms run on differ. The list of "what you need to do when you don't want to compile against the target database" is a long one.
Here is a short list of don'ts
- no +select * from [...]+ views
- no +select * from [...]+ in forms cursors and the like
- %TYPE is evil
- %ROWTYPE is much more evil
Those are just a few obvious things developers can mess up. Of course we all know that this sort of things are bad programming practice but they do happen. And as said: that's just the most obvious things. I work for a vendor where only the compiled files are shipped to the customer, and the road to this goal is a hard and bumpy one. If you don't want bad surprises in production I suggest you implement a fixed build process routine and a fixed upgrade process where you can ensure that the target database where the forms run against match exactly the development database you compile your forms from a logical point of view. The far easier exit is to just compile your forms on the target platform against the target database but I understand that this is not always possible.
cheers

Compile form(frmcmp.sh)

Hi,
There is Oracle Retek patch and module is rms.In patch there is one fmb file.while i am trying to compile it seems hanged Find below steps.I think there is issue with DISPLAY server if yes how could i resolve.
$frmcmp.sh
FRM-91500: Unable to start/complete the build.
$export PROGNAME=recctadj.fmb
$frmcmp.sh
FRM-91500: Unable to start/complete the build.
$export DISPLAY=192.168.125.20:0.0
$frmcmp.sh ---> after running it seems hanged nothing comes
Thnaks
Edited by: userpat on Jun 7, 2010 3:13 AM

Try using a script, for example:
#UNIX Forms Compile
#compile_forms.sh
export FORMS_PATH=/u01/app/oracle/product/source
export DISPLAY=localhost:2.0
#export NLS_LANG=AMERICAN_AMERICA.UTF8
export TERM=vt220
export ORACLE_TERM=vt220
export FORMS_BUILDER_CLASSPATH=/u01/app/oracle/product/source
for i in `ls /u01/app/oracle/product/source/recctadj.fmb`
do
echo Compiling Form $i ....
./frmcmp_batch.sh userid=someuser/password@database batch=yes module=$i module_type=form
compile_all=yes window_state=minimize
done
# May Need to modify $ORACLE_HOME/frmcmp_batch.sh to include FORMS_PATH and other environment variables.
# Copy the frmcmp_batch.sh to /home/oracle or the directory you prefer.
# Change variables as needed make sure you set username password and database connect string

Reports 6i against 10g database

Hi,
We are upgrading our database from 9i to 10g. We are running our reports (6i) against 10g database in the batch mode. For some of our reports we are getting the following error:
REP-0736: There exist uncompiled program unit(s).
REP-1247: Report contains uncompiled PL/SQL.
When report is opened in ReportBuilder it needs to be recompiled against 10g and then it runs fine.
Please advise how to solve this problem.

This is not because of the database is changed. Some of the packages/program units compilation dates might have changed and hence reports wants it to be recompiled.
Rajesh Alex

Show a insert trigger error message on a compiled form

Good Morning
Is there any way to get a oracle complied form to display a message
from a trigger insert event.
My problem is that we have proprietry oracle froms application (with compiled
forms and no source code. I need to raise some sort of warning message
from the form when certain condition occurs.
I have tried using some code like below in the trigger
but the dbms_output.put_line does not output anything
nor the EXCEPTION
DECLARE MY_ERROR exception;
begin
DBMS_OUTPUT.ENABLE;
dbms_output.put_line('outputting this message');
raise MY_ERROR;
EXCEPTION
WHEN others THEN Raise;
END;
thanks
David Hills

You don't need to get at the source code of the form. The example you gave will stop the execution of any process and you said it should happen for an insert event. So a Raise_Application_Error in a database trigger would be sufficient.
Hopefully the vendor has put code in their on-error triggers which will cut the message out of a user-defined exception and display it as an alert (this is so much a better method than returning numbers to indicate success or type of failure). If not then the message will be rather ugly but it will at least get the job done.
James.

Compile Form against UTF8 Database

Similar Messages

Maybe you are looking for