Headstart V6/8i/NT workaround

If anyone's interested, I have a workaround for the server bug which gives ORA-03114 on entry to V6 Headstart-generated forms when run against 8i in an NT environment.
You hit the server bug whenever you have client code which invokes server side procedures using parameters which are either pl/sql records or table of records. Several procedures have such parameters in Headstart's server packages hil_message, qms_message, hil_profile, qms_profile & cg$errors.
The 1st 4 packages have both parameter types, & are invoked a lot from qmslib50 code, so I copied these packages to qmslib50, renaming them (eg hil2_message, qms2_message etc). All calls to these packages within qmslib50 were changed accordingly. I left cg$errors on the server, but overloaded the procedures which had the pl/sql record parameters (there are no table of records), so that they could be invoked using the constituent items of the pl/sql record. I then changed all calls to these procedures from qmslib50 code.
Fingers crossed, it seems to be working.

<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by Cheryl Riley ([email protected]):
If anyone's interested, I have a workaround for the server bug which gives ORA-03114 on entry to V6 Headstart-generated forms when run against 8i in an NT environment.
You hit the server bug whenever you have client code which invokes server side procedures using parameters which are either pl/sql records or table of records. Several procedures have such parameters in Headstart's server packages hil_message, qms_message, hil_profile, qms_profile & cg$errors.
The 1st 4 packages have both parameter types, & are invoked a lot from qmslib50 code, so I copied these packages to qmslib50, renaming them (eg hil2_message, qms2_message etc). All calls to these packages within qmslib50 were changed accordingly. I left cg$errors on the server, but overloaded the procedures which had the pl/sql record parameters (there are no table of records), so that they could be invoked using the constituent items of the pl/sql record. I then changed all calls to these procedures from qmslib50 code.
Fingers crossed, it seems to be working.<HR></BLOCKQUOTE>
null

Similar Messages

I: Headstart 2.1.2, Obsolete Webforms workarounds

Resolved issues in webforms
Headstart for Designer 6.0 and Developer Server 6.0 (patch 5 or higher)
In developer server 6 some issues are resolved where headstart had workarounds for. This document describes the changes that you can apply to
the headstart libraries to remove these workarounds.
1. Show tooltips on the web
In previous developer server versions (before developer 6.0 patch 5), tooltips on the web did not work. As a workaround, tooltips where shown
in the MDI console at the when-new-form-instance. To remove this workaround:
qmsevh50.pll, procedure qms$event_item
Remove the following lines of code:
if qms$help.tooltips_enabled
and qms$application.get_user_interface = 'WEB'
then
qms$item.show_hint;
end if;
qmslib50.pll, package qms$block, procedure init_tooltip
Remove the following lines of code:
if qms$application.get_user_interface = 'WEB'
then
return;
end if;
2. Multiselect SHIFT- and CTRL-click
The problem with multiselect functionality on the web concerned the system variable :system.mouse_button_shift_state. This variable did not
give the right status on the web. The problem can be solved by looking at the variable :system.mouse_button_modifiers. To apply the change,
replace the following procedure in pakage QMS$MSEL:
procedure change_selection
is
l_select_key varchar2(50) := upper(name_in('system.mouse_button_shift_state'));
begin
If (l_select_key = 'SHIFT+'
or g_selection_scope = 'RANGE_SELECT'
and get_range_select_start > 0
Then
SelectRange;
Else
If l_select_key = 'CTRL+'
or g_selection_scope = 'INCREMENTAL_SELECT'
Then
ToggleCurrent;
Else --no interpretable modifier key
If IsSelected
then
unselect_all(name_in('system.cursor_block'));
else
unselect_all(name_in('system.cursor_block'));
SelectCurrent;
end if;
End if;
End if;
exception
when form_trigger_failure then raise;
when others then qms$errors.unhandled_exception('qms$msel.change_selection');
end change_selection;
with this code:
procedure change_selection
is
-- l_select_key varchar2(50) := upper(name_in('system.mouse_button_shift_state'));
-- mva, 05-10-2000 workaround for bug 756682: use mouse_button_modifiers!
l_select_key varchar2(50) := upper(name_in('system.mouse_button_modifiers'));
begin
If (l_select_key = 'SHIFT+'
or g_selection_scope = 'RANGE_SELECT'
and get_range_select_start > 0
Then
SelectRange;
Else
-- If l_select_key = 'CTRL+'
If l_select_key = 'CONTROL+'
or g_selection_scope = 'INCREMENTAL_SELECT'
Then
ToggleCurrent;
Else --no interpretable modifier key
If IsSelected
then
unselect_all(name_in('system.cursor_block'));
else
unselect_all(name_in('system.cursor_block'));
SelectCurrent;
end if;
End if;
End if;
exception
when form_trigger_failure then raise;
when others then qms$errors.unhandled_exception('qms$msel.change_selection');
end change_selection;
null

You mentioned 'the problem with multiselect functionality' but what exactly was the problem? I tried finding the bug 756682 (mentioned in the code) on Metalink but couldn't find it.
Regards,
Edward

Custom forms (with Headstart), issues. Prompted more than once to save/commit.

We have found that after analyzing the APPS schema (for CBO), we
have an issue with custom forms. This issue relates to an
earlier post on this forum where we get prompted several times
to save/commit our changes and that the changes are never
submitted. We've narrowed it down to the QMS_TRANSACTIONS
table, when ever we run...
analyze table apps.QMS_TRANSACTIONS estimate statistics;
Table analyzed.
Our custom forms will stop working. Why is this? So far we've
found the only work around is to drop all Headstart objects and
run the scripts to recreate the objects in the APPS schema.

Michael,
This might be a similar problem as they have experienced in
Japan. Their problem description is as follows;
-At the beginning, the transaction can be committed from the
screen.
-After analyzing APPS schema, it becomes impossible to commit the
transaction.
This problem is reproduceable in following condition;
-Use Oracle 8i 8.1.7.x.
-Set '_push_join_union_view' parameter to true. (Set by Rapid
Installer of EBS)
-Analyze the schema that has qms_transactions table.
This problem seems to be caused by DB bug (Bug no 2058756).
If this is indeed your problem a workaround has been described to
set the event 10195 before analyzing the table.
Hope this helps.
Regards,
Sigrid Gylseth.

Closing Application - Headstart bug?

This mail was originally posted on the ODTUG maillist.
I am using Headstart Qms 5.0 and we are having problems with closing the
application window using the Windows Close button[x]. Detailed description
follows:
When window is closed by pressing the 'x' found at the right topmost part of
the screen, a message appears confirming whether to commit, not commit or
cancel changes. Once cancel button is pressed, it creates infinite loop or
sometimes shows the same message several times.
The temporary workaround was to comment out the before code added by QMS in
the key-exit trigger: qms$event_form('KEY-EXIT');
/* CGAP$TES_SEQUENCE_BEFORE */
/*begin
qms$event_form('KEY-EXIT');
end; */
/* CGNV$CLOSE_ALL_WINDOWS */
BEGIN
CGNV$.nav_enter_query := FALSE;
IF (:SYSTEM.MODE = 'ENTER-QUERY') THEN
exit_form;
ELSE
CGNV$.CLOSE_ALL_WINDOWS;
END IF;
END;
/* CGAP$TES_SEQUENCE_AFTER */
begin
qms$event_form('KEY-EXIT','AFTER');
end;
Although this solves the problem of infinite loop, this needs to be further
investigated because the code is actually handling the case where system
mode is 'ENTER-QUERY':
procedure close_current is
-- Purpose: Exit form, regardless of form mode
begin
-- Cancel query mode when running in query mode, and then
-- perform do_key('exit_form') as OFG generates code in KEY-EXIT trigger
to close
-- child forms when preference NAVCCF is set to Yes
do_key('cancel_query');
if name_in('system.mode') = 'ENTER-QUERY'
then
copy('10','system.message_level');
exit_form;
copy('0','system.message_level');
end if;
g_closing_current := true;
do_key('exit_form');
exception
when form_trigger_failure then raise;
when others then
qms$errors.unhandled_exception('qms$form.close_current');
end close_current;
Looks like a Qms bug to me. Is anyone familiar with this? All help highly
appreciated.
Rgds,
Siggi

This reply was originally posted on the ODTUG maillist.
I ran into this problem. It was a Forms 5.x bug. It was definitely fixed
in 6.0. I can't remember the patch set in 5.0 that fixed it. It was not a
Headstart problem, but rather a Forms bug.
Mari Cobb
Oracle Certified Professional
Independent Consultant
Sacramento, California www.ms-mari.com
null

Headstart prevents using Module components based on IOTs

I want to build a module component based on an index-organized
table. The following Designer + Headstart behaviour prevents
correct functioning of such a block:
- Block property 'Enforce Primary Key' must be set
- Block Property 'Key mode' must be set to 'Non Updatable'
- 'Primary Key' property of PK items must be set
- The event ON-LOCK calls qms$record.unlock, which calls
the lock_record built-in. This should not be done for an IOT.
Solutions:
- I have made new source objects for IOT Block and PK items,
and assign these to the MC and bound items when applicable.
- I modified the ON-LOCK event to not include the lock_record.
The qms$record.unlock procedure is obsolete anyhow, since it
is a workaround for an old (solved) bug.
Headstart Team:
I recommend you include these workarounds in the standard object
library and pl/sql library.

Peter,
Thanks for your feedback. I have posted an enhancement request
for the next release of Headstart.
Regards,
Lauri

Problem with Headstart Multi-Select LOV

Hi,
I'm working on a few forms which should include a Multi-Select
LOV. Now here's the problem: One MSEL doesn't close; you can
select record(s), the LOV returns them, but doesn't disappear.
Clicking Cancel doesn't help.
Another MSEL-problem in another form: if you click Select All,
this selection isn't visible in the MSEL. He returns all of the
records, but it looks like he only selected one. Working with
CTRL to select more than one record doesn't work either. This
one closes fine.
As you know I have to include module component
QMS_MSEL_LOV_BUTTONS (which includes all button-functionality),
and then it should work, but it doesn't.
We've checked all the properties and they seem to be correct. It
isn't the first time we encountered these problems. We always
rebuilt the MSEL LOV, but it doesn't help this time.
Has anyone got an idea what's causing this problem.
P.S. There are also MSEL LOV's which operate just fine, without
any problems; only these two are doing strange things.
Thx,
Wouter

Workaround provided by Lauri Boyd seems to have worked:
A bug (#1985903) was introduced in Forms 6.0.8.13.0 and later which affected Headstart. This was fixed in Headstart patch 6.5.2.1 which is available through the Supplement Option.
Description
===========
1. When using a multi-select LOV (which is displayed in a modal dialog
window), you select the records you want, press OK, and the application exits.
2. When using a shuttle control to move records from left to right or vice
versa, you select the records you want, press '>' to move them, and the
application exits.
This occurs in Forms 6.0.8.13.0 and 6.0.8.14.1. It did NOT occur in prior
releases. This is some kind of forms bug.
Workaround
==========
For some reason the call to procedure renumber in qms$msel.process_records
causes the application to exit. If you copy the code from renumber to all the
places from which it is called, it works fine.
- open qmslib65.pll in Form Builder
- open package body qms$msel
- find procedure process_records and define a local variable l_recno of type
number.
- find local procedure renumber and copy the body of this procedure
(everything
after 'begin' and before 'exception').
- replace each call to 'renumber;' with the copied code.
Regards,
Lauri

Is Headstart 6i compatible with all Designer 6i versions? Where to download?

We consider upgrading from Designer 6.0 / Headstart patch 12.4
to Designer 6i / Headstart 6i, as we are now migrating from a
7.3.4 db to 8.1.7 and from Win98 to Win2000.
I have seen documentation on migration issues from Designer 6.0
to 6i rel.2, and from Headstart to patch 13. But I understand
that with introduction of Headstart 6i, patch 13 is no longer
supported.
1. I assume that Headstart 6i could work with all Des.6i-
versions, is that right?
2. I have found the place to download patch 13, but where can I
download Headstart 6i ???

Headstart 6i is compatible with all Designer 6i versions.
However, we have found one odd quirk with Headstart 6i and Forms
6i versions 6.0.13 and higher.
Description ===========
1. When using a multi-select LOV (which is displayed in a modal
dialog window), you select the records you want, press OK, and
the application exits.
2. When using a shuttle control to move records from left to
right or vice versa, you select the records you want, press '>'
to move them, and the application exits. This occurs in Forms
6.0.8.13.0 and higher. It did NOT occur in prior releases. This
is some kind of forms bug.
Workaround ==========
For some reason the call to procedure 'renumber' in
qms$msel.process_records in qmslib65.pll causes the application
to exit. If you copy the code from renumber to all the places
from which it is called, it works fine.

Headstart 6i - no client/server support?

Hello,
I have received today list of some new features of Headstart 6i (Beta supposed to be available this week).
In the new features list, here what it is wrote:
<<Because of known issues associated with running Forms 6i in a client-server environment, Headstart 6i will not be certified for client-server deployment. Applications can still be deployed client-server, but Headstart will not attempt to identify and overcome client-server specific issues.>>
Is someone have heard about these "known issues" in client/server?
Thank you
Jean
null

The problems are GUI issues.
The basic problem is this:
Headstart can either be optimized to display in Webforms with the Oracle Look and Feel, or it can be optimized to display in client-server mode. You can't do both at the same time. Since we had to pick one or the other, we chose the Webforms OLAF GUI settings.
You can customize the template package to revert to the client-server GUI settings if you like. This basically involves changes to the visual attributes in the object library, removing the use of the keyword 'automatic' and setting actual colors for foreground color, background color and fill pattern.
There are also problems with displaying the menu and Smartbar. You should remove the icons that are displayed in the menu. If an entire menu group is disabled, the associated icons on the Smartbar disappear instead of greying out (no workaround).
There might also be other GUI issues. As stated, we have not tried to identify or resolve these issues.
Regards,
Lauri

Headstart

I installed oracle designer 6.0 for NT. I also installed the Headstart patch which supposedly works with designer 6.0. However, when I try to log on to the Headstart demo application, it comes back with FRM-40733, FRM-40735 and ora-03114 messageS. The database I am using is 8.1.5.
I have noticed that the ofg libraries available in the cgenf60/admin directory for designer 6.0 have been compiled with Forms 5. Does that have anything to do with it or is it the fact that I am using 8.1.5 Database

<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by Sandra Muller, Headstart Team, Oracle:
Can you give more details about your situation? Which patches of Headstart have you installed (10, 11, 12?) and did you apply the workaround for using Headstart with Oracle 8.1.5 on NT? (not valid for patch 12!) When exactly do you get these messages (when you try to do what, with which user)? What are the texts that go with FRM-40733, FRM-40735 and ORA-03114?
By the way, the bug that caused the problems on Oracle 8.1.5 for NT is solved in Oracle 8.1.6. You can use Designer 6.0 with Oracle 8.1.6 if you install Designer patch set 4.
regards,
Sandra Muller<HR></BLOCKQUOTE>
The headstart patch I used is 10 which I downloaded from OTN. The user I used was Hsdemo which I created. I used the server install form to install the demo application under this user.
By the way I installed Oracle 8.1.6 and the problem disappeared.
Is patch set 4 available for downloading from OTN or do I have to order it from Oracle?
Thanks for the reply.
null

Error Headstart in combination Designer 6, Developer 6 HELP

We have upgraded to Desigener 6.0 and Developer 6.0 (patch 6).
All the pll's compile when (qmslib50, qmsevh50), the generation of a small application in Designer 6 (was first in Designer 2.1.2) went well.
When we run the forms we get the following error "FRM-40733 PL/SQL Build in DBMS_ERROR_TEXT failed. I'm searching for two days and haven't come up with a solution
Please help !?

You are probably using an Oracle 8.1.5 database an running against Oracle RDBMS problem report 966970. Oracle Support has tested
it against an 8.1.6 database and there the problem is fixed. There is also a workaround available for 8.1.5, see the Headstart discussion
forum on OTN and look at the e-mails of Cheryl Riley (thanks Cheryl). I suggest however that you move to 8.1.6.
Regards,
Ton

Headstart Utilities Failure w/Designer 6.0

Hello:
I've just tried to install Headstart 2.1.2 with the new patches
for Designer 6/Developer 6 on Windows NT 4.0 SP 4. I've checked
all of the logs (in my ORANT\HSD21 folder) and I don't see any
errors in any of them.
However, when I go to start the Headstart Utilities
Administration and log in as the Headstart Utilities owner, I
get the following:
I get a number of "FRM-40733: PL/SQL built-in DBMS_ERROR_TEXT
failed". This comes up 5 times in a row.
Then I get "FRM-40735: PRE-FORM trigger raised unhandled
exception ORA-03114". This comes up once, and the form exits.
This last one seems to indicate that the logon has failed, but I
can log on using SQLPlus 3.3 and SQLPlus 8.0 with no problems,
using exactly the same ID/password.
If it matters, I'm using Oracle 8.1.5.0.0, Developer 6.0
downloaded from Technet with the dev60 patches and Designer 6.0
with no additional patches. They all seem to be working OK
(I've generated a test form w/o Headstart and it runs OK).
I've also run the following as suggested in another of your
posts:
select object_name from user_objects where status='INVALID';
which returns no rows.
Help!!
TIA
Eric Raskin
null

Headstart Team (guest) wrote:
: Jeff Esposito (guest) wrote:
: : Headstart Team (guest) wrote:
: : : Eric Raskin (guest) wrote:
: : : : Headstart Team (guest) wrote:
: : : : : Eric Raskin (guest) wrote:
: : : : : : Hello:
: : : : : : I've just tried to install Headstart 2.1.2 with the
new
: : : : patches
: : : : : : for Designer 6/Developer 6 on Windows NT 4.0 SP 4.
: I've
: : : : : checked
: : : : : : all of the logs (in my ORANT\HSD21 folder) and I
don't
: : see
: : : : any
: : : : : : errors in any of them.
: : : : : : However, when I go to start the Headstart Utilities
: : : : : : Administration and log in as the Headstart Utilities
: : owner,
: : : : I
: : : : : : get the following:
: : : : : : I get a number of "FRM-40733: PL/SQL built-in
: : : : : DBMS_ERROR_TEXT
: : : : : : failed". This comes up 5 times in a row.
: : : : : : Then I get "FRM-40735: PRE-FORM trigger raised
: : unhandled
: : : : : : exception ORA-03114". This comes up once, and the
form
: : : : exits.
: : : : : : This last one seems to indicate that the logon has
: : failed,
: : : : but
: : : : : I
: : : : : : can log on using SQLPlus 3.3 and SQLPlus 8.0 with no
: : : : problems,
: : : : : : using exactly the same ID/password.
: : : : : : If it matters, I'm using Oracle 8.1.5.0.0, Developer
: 6.0
: : : : : : downloaded from Technet with the dev60 patches and
: : Designer
: : : : 6.0
: : : : : : with no additional patches. They all seem to be
: working
: : OK
: : : : : : (I've generated a test form w/o Headstart and it runs
: : OK).
: : : : : : I've also run the following as suggested in another
of
: : your
: : : : : : posts:
: : : : : : select object_name from user_objects where
: : : : status='INVALID';
: : : : : : which returns no rows.
: : : : : : Help!!
: : : : : : TIA
: : : : : : Eric Raskin
: : : : : Eric,
: : : : : I'm sorry to say I have bad news for you. The error you
: run
: : : : into
: : : : : is caused by the following bug in Forms 6.0, which only
: : : : : reproduces with Oracle 8.1.5 on NT:
: : : : : 966970: CONNECTION LOST WHEN INVOKING PACKAGED
PROCEDURE
: : WITH
: : : : : PLSQL-TABLE AS ARG OFMO899
: : : : : Only work around is to use 8.0.5, or 8.1.5 on a UNIX
: : machine.
: : : : You ain't kiddin' about the "bad news" part, are you?
: : Just
: : : : to be sure I understand, this is only on the development
: : : : machines, right? I can still run 8.1.5 on NT for the
: actual
: : : : database?
: : : : Eric
: : : I wish I was kidding! This is a problem you might run into
on
: : : your production database as well. The moment you have a
forms
: 6
: : : application that calls a server-side procedure which has a
: : PL/SQL
: : : table of records as parameter, the connection is lost.
: : : Headstart-generated applications will all run into this, as
: : : Headstart uses such a server-side procedure for message
: : : handling.
: : : We have raised this issue with Forms Development, and have
: : asked
: : : for a patch. (although it might turn out to be a server bug
: : : instead of a forms bug...).
: : This is very bad news, as I was looking to leverage
: : headstart with 8.1.5/Designer/Developer 6.0 for rapid
: development
: : and deployment of an application to the web.
: : I'm sure there are a few of us in this boat.
: : Questions:
: : 1) Does this problem exist for 8.1.5 in a Unix deployment?
: : Specifically, can I be assured of reliable forms generation
via
: : headstart if my 8.1.5 database lives in Unix?
: : 2) Assuming Forms Development agrees with you and is working
on
: a
: : patch, may I offer to help test that patch?
: : Jeff
: Jeff,
: This is only a problem with Oracle 8i on NT. Note that it is
not
: just a Headstart problem. If you generate a form with Designer,
: and the block is based on a MAPI procedure, it won't run on
8.1.5
: on NT either, because the MAPI procedure has a PL/SQL table of
: records as a parameter, just like the Headstart message
handling
: routine. Thanks for your offer, but given the wide impact of
this
: bug, Oracle will be able to create sufficient testcases
: themselves.
Hello,
does the same problem exist on Oracle 8.0.5 on Windows NT and/or
Digital Unix too?
We are currently thinking about using Headstart and if the
problem exists on 8.0.5 the workaround you provided might be a
big problem for us ...
thx in advance
null

Headstart using Forms servlet implementation

I'm trying to configure forms server with headstart 6.5 using the servlet implementation. Almost everything is working fine, except one detail.
The formsweb.cfg file has "%HSD65_HOME%" values (e.g. the term tag), which must be substituted by the value in the registry. When using CGI, the substitution is made. The servlet implementation results into a substitution of "".
Can anyone explain why this isn't working (bug)?
Thanx,
Patrick van der Schot

Peter,
I've tried both suggestions. They didn't work. Reading windows registry values is not supported in the standard Java libary because it's not portable. There are native methods like the implementation JAWIN, an open-source project for interop between Java and Win32 (http://staff.develop.com/halloway/JavaTools.html). Putting the HSD65_HOME setting in the configuration files of the webserver doen't work either.
I've used a workaround to get things working. I've substituted the full path into the term tag instead of using term=%HSD65_HOME%/hst/admin/qmsrf65w.res.
Don't forget to change the FormsServlet.InitArgs settings to use the corresponding headstart basejini.htm and hsdcgi65.cfg
For servlet implementations, the baseHTML, baseHTMLJInitiator, and baseHTMLIE
tags are replaced with the values specified in the FormsServlet.initArgs file!
Patrick van der Schot
null

Create CAPI definition problem with Headstart 6i / Designer 6i rel. 4.3

During migration from hsd50/des60 to hsd65/des6i rel 4.3 of an application using CDM ruleframe: according to the migration guide, one step is "Upgrading Existing CDM RuleFrame objects", which includes running the Create CAPI definition (Headstart utility). After that step we assume de created CAPI's should be generated together with the Table API. But executing the CAPI-scripts results in errormessages. After comparing the 60 and 6i versions, we found a bug, probably caused by the Headstart utility: In the package body, after the header of the first function of the Business Rule Check Functions, suddenly the declaration section of the package is again inserted, and after that the first function is again defined followed by the rest, causing also a missing end statement at the end of the package.
Is this known, and if so, is there a fix available?
Regards, Paul.

Paul,
We have found the cause for your other problem (the repeating of the declaration section).
With 6.5 a new package property Private Declaration was introduced in Designer.
This property should officially be used instead of PL/SQL block to specify package body declaration
(assuming you define all package procedures and functions in separate PL/SQL Definitions).
However, at first the migration from an earlier version of Designer did not pose any problems
because of Designer bug 1470283. That's why you won't find anything about this in the Headstart Migration Guide.
Now that Designer bug is fixed, migrating a CAPI causes part of the PL/SQL Block to be moved to the Private Declaration.
If you then generate the CAPI package to the database, it works fine, but when you run the CAPI utility again,
it inserts the package declarations again in the PL/SQL Block (leaving the Private Declaration in tact).
That's when you get duplicate package declarations. We logged this as Headstart bug 2527128.
You already found a workaround: deleting the CAPI and generating it again. Another workaround is
moving the Private Declaration to the top of the PL/SQL Block (this allows you to keep your existing
Revision History).
Hope this helps,
Sandra

FRM-41085 when starting Headstart

I get the FRM-41085 error message when starting Heastart
-generated application. As I understand this error is raised if I
try to run the application under an Oracle user who doesn't
access to Headstart DB objects ... but my application shows the
startup form without loggon and I perform the loggon later. The
message is raised before the user has the chance to logon !
Is here any workaround ?
Robert
null

Robert Carnecky (guest) wrote:
: I get the FRM-41085 error message when starting Heastart
: -generated application. As I understand this error is raised if
I
: try to run the application under an Oracle user who doesn't
: access to Headstart DB objects ... but my application shows the
: startup form without loggon and I perform the loggon later. The
: message is raised before the user has the chance to logon !
: Is here any workaround ?
: Robert
No, at forms start-up, Headstart performs a number of
initializations that require database access. It is therefore not
possible to postpone the logon.
null

Upgrading to Headstart Ruleframe

At the moment we have several applications running. Some have been build using
Headstart Desinger/2000, while others have been build using Headstart
Ruleframe.
Of course, because of this we have to maintain both versions of Headstart. We
would like to use only one version of headstart, Headstart Ruleframe.
Is there any information on how to easily migrate the applications using Headstart
Designer/2000 to Headstart Ruleframe?
Is it possible to regenerate an application replacing Headstart Designer templates and libraries with those of Headstart Ruleframe?
Which steps are involved?
Appreciate your help!
null

Matthijs,
Yes, it is possible to migrate the Headstart software to the new versions (i.e. patch 12) without really starting to use CDM RuleFrame.
In each form that will be recompiled after you upgraded Headstart to patch 12, there will be a call to qms_transaction_mgt.open_transaction and close_transaction. So these packages should be installed but because no business rules are put on the rule stack (TAPI does not call CAPI package), the close_transaction will always succeed.
Notice that several utilities will be disabled after installation of CDM RuleFrame (e.g. the utility to workaround the Mutating Table problem, which has become obsolete as soon as you start using CDM RuleFrame).
Kind Regards, Marc

Headstart V6/8i/NT workaround

Similar Messages

Maybe you are looking for