Bug Forte F
Hi to everybody,
I hope you can help me.
I was wondering if someone knows about bugs of Forte release F.
We had a client server application developed with Forte Express (client
Windows NT, server Sun Solaris) that starts at 08.00 a.m. every day.
At beginning clients connect to the server (cluster Sun) until circa
8.50 a.m. gradually, then at 9.10 a.m. they are more numerous until we
have almost 400 clients connected.
Usually between 9.00 and 9.30 a.m. the node manager crashes. I specify
that the memory setted with -fm flag is more than double of used memory
and there are no other different processes started on the server during
this period.
We don't think that it could be a problem due to the application
because, in this case, the partitions (compiled) should crash but, on
the contrary, they stay up.
Thanks anyway and happy new year,
Dr. Tesi Giovacchino
Fortè Developper
Telesoft S.p.A.
Hi to everybody,
I hope you can help me.
I was wondering if someone knows about bugs of Forte release F.
We had a client server application developed with Forte Express (client
Windows NT, server Sun Solaris) that starts at 08.00 a.m. every day.
At beginning clients connect to the server (cluster Sun) until circa
8.50 a.m. gradually, then at 9.10 a.m. they are more numerous until we
have almost 400 clients connected.
Usually between 9.00 and 9.30 a.m. the node manager crashes. I specify
that the memory setted with -fm flag is more than double of used memory
and there are no other different processes started on the server during
this period.
We don't think that it could be a problem due to the application
because, in this case, the partitions (compiled) should crash but, on
the contrary, they stay up.
Thanks anyway and happy new year,
Dr. Tesi Giovacchino
Fortè Developper
Telesoft S.p.A.
Similar Messages
-
Ivor Vaz@SUNLIFE
08-11-97 12:57 PM
Hello,
Does anybody know of a work-around for using MS-SQL stored procedures with
complex select statements to build cursors in forte ?
I have to use a select statement that contains a union. When I do an
OpenCursor Forte returns an exception error. This is a know limitation
with Forte, ODBC and MS-SQL. It is listed as bug number 22023.
I would greatly appreciate any suggestions.
Thank You
Ivor VazThe problem was solved by defining the method as inline and implementing it in the header file. I am now even more sure that this is a bug in the Forte C++ 6.0U1, but I have to check the patch levels of my development environment before I'll report it as such to Forte development team.
Of course any other comments are still wellcome :-). -
Forte 6U2 C++ compiler bug
In the Forte 6U2 compiler, a function return can implicitly invoke a conversion constructor that is marked "explicit".
Consider:
class ABaseClass {};
template<class Type, class Uncert>
class Value
public:
Value(Type const& t, Uncert const& u) : _t(t), _u(u) {}
protected:
Type _t;
Uncert _u;
class Foo : public Value<float, double>, public ABaseClass
public:
explicit
Foo(ABaseClass b=ABaseClass(), float val=-1, double tol=0)
: ABaseClass(b), Value(val, tol)
std::cerr << "Explicit constructed Foo\n";
class Bar : public Value<int, double>, public ABaseClass
public:
explicit
Bar(ABaseClass b=ABaseClass(), int val=-1, double tol=0)
: ABaseClass(b), Value(val, tol)
std::cerr << "Explicit constructed Bar\n";
class Context
public:
Context() : _foo(ABaseClass(), 1.23, 0.45) {}
Bar getFoo() const
return _foo;
private:
Foo _foo;
int main()
Context c;
c.getFoo();
}Note that Context::getFoo has a type mismatch between the declared return type and the return value. This is a bug that was not caught by the compiler. Intstead, Bar(static_cast<ABaseClass>(_foo)) is invoked and
returned. The output of this run is:
Explicit constructed Foo (Context constructor)
Explicit constructed Bar (Context::getFoo return)
This behavior is non-standards conforming.-xO2 is enough to cause the failure.
Making the vulnerable pointer "static" fixes the problem, although this should make no difference.
My guess is over-eager register reuse, but I'm open to alternative theories. -
Mangling bug in Forte 6.1 Update 1 ?
Hi,
I built the following code
Foo.h >>>>>>>>>>>>>>>>>>>>
class Foo
public:
typedef Foo Bar;
void mangle( const Foo&, const Bar& );
<<<<<<<<<<<<<<<<<<<<<<<
Foo.c >>>>>>>>>>>>>>>>>>
#include "Foo.h"
// Version 1
void Foo::mangle( const Foo&, const Foo::Bar& ) { }
// Version 2
// void Foo::mangle( const Foo&, const Foo& ) { }
<<<<<<<<<<<<<<<<<<<<<<<<
The strange thing is the both version 1 and 2 of the implementation of the
method compile with "CC -C Foo.c", as I think is correct.
However they mangle to different symbols in the resulting .o file
Version 1 : __1cDFooGmangle6Mrk0r1_v_
Version 2 : __1cDFooGmangle6Mrk02_v_
Both these symbols demangle to : "void Foo::mangle(const Foo&,const Foo&)"
I a real world example this caused us some stange link time failures.
Am I right in thinking the both implementations are allowed and that
this a compiler bug?
David Hunter
Lehman BrothersHi,
I am not C++ guru, So I don't whether this is a bug or not.
But, in past somebody had given following workarounds
to me:
1. Use typedefs everywhere or nowhere.
2. Use Pragma weak, specifying the mangled names as quoted strings.
3. Use "-Qoption ccfe -abiopt=mangle6" . Note, however, that this option may prevent linking with some libraries.
Hope this helps.
Thanks
Kalpesh -
Crazy preverifier bug using forte
I boot my Windows 98SE machine and execute my test Midlet from forte with total success, however the second time I try to execute it I receive a "Cannot start preverifier" error. If I reboot my machine it works again, but only the one time. It is almost like the preverfier app is not closing itself down when it has verified the class first time. Can anyone help remedy this problem?
Any help very much appreciated
MatIn order to get it work, I have to press F6 a few times. I believe that it's something to do with forte not waiting for the compiler to finish before running the verifier.
-
Forte 6u1 C compiler bug? Worse in 6u2?
I have a rather large program containing a function which misbehaves intermittently with -xO3 optimization. The failure occurs on perhaps one run in ten.
A pointer variable local to the function appears to be corrupted by a call to another function. (It's ok before, and bad after the call.) The corrupted pointer value then usually causes a BUS error, rarely a SEGV (depending on its divisibility by 8, I assume).
Adding printf() calls showed the corrupt value (lately, 0x800000002 has been popular) using 6u1. After updating to 6u2, the intermittent corruption remains, but now the printf() itself fails, as it apparently tries to dereference the pointer (for some mysterious reason) instead of just displaying it. Dbx (6u2) says:
Read from unallocated (rua):
Attempting to read 1 byte at address 0x800000002
stopped in _doprnt at 0x7fef5189d54
0x000007fef5189d54: doprnt+0x0160: ba,a doprnt-0xda41c
(/opt/forte6u2/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) where
=>[1] _doprnt(0x100327630, 0xffffffff7fffefc0, 0x100327630, 0xff291400, 0x0, 0x0), at 0x7fef5189d54
[2] _fprintf(0x0, 0x800000002, 0x7fef52be228, 0x0, 0xffffffffffffffff, 0x100327db0), at 0x7fef518d088
[3] <my_stuff ...>
The (newly) offending statement looks like this:
fprintf( pfCFile, " a = %016lx.\n", assign);
where "assign" is the pointer to a structure of some sort.
Does anyone have any helpful hints or will I need to spend the $1599 to create an incident?-xO2 is enough to cause the failure.
Making the vulnerable pointer "static" fixes the problem, although this should make no difference.
My guess is over-eager register reuse, but I'm open to alternative theories. -
Sun Studio 11 CC's Bug? Compared with Forte
class proc_pdu_cursor
friend proc_pdu;
private:
bool set;
prp_cursor cursor;
operator prp_cursor*() const;
public:
proc_pdu_cursor();
proc_pdu_cursor(const proc_pdu_cursor &);
proc_pdu_cursor(const prp_cursor c);
proc_pdu_cursor& operator=(const prp_cursor c);
proc_pdu_cursor& operator=(const proc_pdu_cursor&);
friend bool operator==(const proc_pdu_cursor& lhs,
const proc_pdu_cursor& rhs);
friend bool operator!=(const proc_pdu_cursor& lhs,
const proc_pdu_cursor& rhs);
bool is_set() const;
bool is_null() const;
void dump() const;
proc_pdu_cursor& reset();
prp_cursor cont() const { return cursor; }
class proc_cursor {
private:
static void * dup_f(void*);
static void clear_f(void*);
//protected:
void * (*dup)(void *);
void (*clear)(void *);
void * curs;
public:
proc_cursor(void);
proc_cursor(const proc_cursor&);
proc_cursor(void *, void*(*)(void*), void(*)(void*));
void * get(void) const {return curs;}
proc_cursor& operator=(const proc_cursor&);
virtual ~proc_cursor(void);
class PDUCUR: public proc_cursor
private:
static void * dup_f(void* dat) { return dat; }
static void clear_f(void*) { }
public:
PDUCUR();
PDUCUR(const PDUCUR &);
PDUCUR(const prp_cursor);
PDUCUR(const proc_pdu_cursor &);
~PDUCUR() { }
where process invokes:
int MCB::dispatch_link_pdu(proc_pdu& lpdu)
PDUCUR cursor(proc_pdu_cursor());
int req = lpdu.get_command();
proc_pdu_cursor c1;
if (lpdu.next_peer(c1))
if (lpdu.get_ref_qual(c1).category() == "SD_PREFIX") mPrefixCur = c1;
cursor = mPrefixCur;
mPrefixCus is member varialbe of class proc_pdu_cursor to MCB.
While Forte6.1 passed this file's compilation.
but Studio11 Failed and offered an error:Error: The operand "*cursor" cannot be assigned to.
Even I updated the member function of PDUCUR& operator =(const proc_pdu_cursor&), it still encounter such a problem. Who can help me, thanks.You don't show enough of the code to determine what is wrong. The code example uses types proc_pdu and proc_pdu_cursor, which are not defined. The function at the end where you have the problem is a member of class MCB, which is not defined.
Try reducing the test case to remove references to types that don't matter, and provide stub definitions of classes that do matter. (By "stub", I mean just enough declarations in the classes to let the code compile and still show your problem.)
Verify that you can compile the code wtih FD6u1 but get the error wtth Studio 11.
The Forum posting sofware tends to mangle code examples, so enclose the code in "code" brackets. -
This piece of code does not link with -xO2. The error is along the line "missing symbol XX_T" ....
#include <iostream>
char const * const XX_T = "XX";
template<class T>
class MY
public:
void print();
template<class T>
void MY<T>::print()
{ int i = XX_T[0]; } // if moved into the class declation then it'll work ....
main() { MY<int> t; t.print(); }Hi there,
This particular example is valid C++, but Sun's compiler does not support it. Please refer to the
compiler documentation rgarding references to objects or functions with internal (static) linkage
from templates.In C++, a file-scope or namespace-scope object declared const has internal linkage unless explicitly declared extern.
Add "extern" to the definition of XX_T and the code will compile and link.
If you don't want to give XX_T global scope, put it in a namespace, or make it a static member of the template class, or make it a local static variable in the print function.
....jagruti
DTS
Sun Microsystems Inc. -
RE: (forte-users) 3J= 3M new to me error
Hi Thomas,
Thanks for your email but I think it will be interesting for Brenda not me.
It is exactly what I have expected from Forte Support: detailed information
about bugs and workarounds. But what I cannot understand is that #53398 was
released without any information about possible reasons for this problem or
suggested workarounds. My first reaction after reading this bugreport was to
open a new case at CallCenter to get more information about it. Please
release more information with your bug reports !
Regards
Zenon Adamek
Information Services
Senior Programmer Analyst
Tel: 905 712-1084 ext. 3628
Fax: 905 712-6709
E-mail: zadamekpurolator.com
-----Original Message-----
From: Thomas Degen - Sun Germany Forte Tools - Bonn
[SMTP:thomas.degensun.com]
Sent: Wednesday, September 27, 2000 9:49 AM
To: Adamek, Zenon
Cc: 'Brenda Cumming'; Forte-userslists.xpedior.com
Subject: RE: (forte-users) 3J=>3M new to me error
Hi Zenon,
bug #53398 is not a bug which will likely get fixed, it's an informational
bugreport.
You might see an errorstack like Brenda has reported (and described in
informational
bugreport #53398) probably when you are doing something illegal that is
possible
via Forte Tool but Forte is not trapping it for performance reasons. Hence
you will see
the error coming from your illegal operation only at runtime, probably
only
while
running interpreted in the Forte IDE, but in worst case it might be even a
segmentation
violation.
Technotes 12448 'Sudden client partition crashes at runtime' and 11225
'Don't reparent
mapped Widgets between UserWindows at runtime' explain this matter . See
attached.
But maybe Brenda is much more experiencing a problem as described by Forte
Technote 11398 'Read Only Workspace Errors using ListViews or ActiveX
control'
that might get easily resolved via setting of FORTE_YIELD_THROTTLE=0.
Good Luck and Best Regards !
BTW: I've logged bug #53398, so I've felt responsible to explain its real
background.
Thomas
Thomas Degen
Sun Microsystems - Forte Tools
Forte CTE & Sustaining Group
Technical Support Germany
tel.:+49.228/91499-50
MailTo:thomas.degensun.com
Technote 11398 Read Only Workspace Errors using ListViews or ActiveX
control
SCENARIO:
Getting some unusual interpreter errors that result in an error stating
that
the workspace has been set to read only. Please see Enclosures for the
two
most common error stacks that have been encountered. The abbreviated
versions of the errors are:
- Can't read record (record size = -1)
- Id in index does not match id in record header in data file
- Recursive deserialization attempted.
- Unknown Mark type in deserialization
- Could not read record (64,74615) from repository data file.
Header
is corrupt.
These errors can be happening in either the development environment when
running from one of the development workshops, or with the deployed
application.
The bug outlined in this Technote may be the culprit if the errors above
are
seen when running a client on Windows NT or Motif and the user interface
incorporates ActiveX controls or ListView/TreeView widgets.
CAUSE:
Basically what is happening is that in rare circumstances Forte may invoke
a
nested copy of the interpreter while the first interpreter has yielded.
This
is not a problem in and of itself, but in the case where the original
interpreter was in the middle of a repository fetch when it yielded, and
the second interpreter needs to fetch code as well, we will get one of the
errors listed above, depending on the exact timing. The reason for the
errors is that the repository code at this level is thread-safe but not
re-entrant. It is protected by a mutex that is already owned by the
current task. Which, given the scenario outlined here, where the two
interpreters are running inside of the same task, results in the nested
interpreter being allowed to change data out from under the first.
While for every fetch one or more calls to WindowSystem.Yield will be made
(this is there to prevent the semblance of system lock-up on Win 3.1,
where
Yield is the only way other applications can be allowed to run), there is
a parameter which controls how often to actually yield, which by default
is
set to one out of every 100 calls. This is the reason the problem is
intermittent--you need a yield to occur during a repository fetch
which starts another interpreter which also needs to fetch code from
disk.
The reason this has only surfaced recently is that the nested interpreter
scenario can only happen in 2 cases that we know of:
- ActiveX controls which respond to events/Windows messages
- Outline fields/ListViews with column(s) mapped to virtual
attributes
In all other normal cases, the yield can process the message (typically a
paint message) without starting another interpreter, so regardless of
whether
the first interpreter yielded during a repository operation or not, there
is
no conflict.
SOLUTION:
The workaround is to prevent yields altogether by setting the
FORTE_YIELD_THROTTLE environment variable equal to 0 in the client's
environment. This should have no detrimental effects since the yield code
is in place solely for Windows 3.1x clients.
ERROR STACK 1
SYSTEM ERROR: Because of a prior error, your workspace was set to
read-only to
prevent the application from attempting to write to the repository. The
repository and work you have saved to the repository are safe. If your
workspace
contains unsaved work, you may use the following procedure to save this
work.
First, export the changed components. Then, shut down and restart this
application and reopen this workspace in read-write mode. Finally, import
the
changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 695]
Detected at: qqrp_Session::GetObjectById
Last TOOL statement: method EFWindowController.EFEventLoop
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
The remainder of the Error Manager stack is:
SYSTEM ERROR: Internal Error attempting to deserialize element (64,67470)
(fetch
bitmask is 0x20). Your workspace is now read-only to prevent the
application
from attempting to write to the repository. The repository and work you
have
saved to the repository are safe. If your workspace contains unsaved work,
you
may use the following procedure to save this work. First, export the
changed
components. Then, shut down and restart this application and reopen this
workspace in read-write mode. Finally, import the changed components and
save
your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 61]
Detected at: qqrp_LogicalSession::MaterializeObject
Last TOOL statement: method EFTabManagerNew.EFNoteBookHandler
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
SYSTEM ERROR: Unknown Mark type in deserialization.
Class: qqsp_ImplementationException
Error #: [1101, 34]
Detected at: qqrp_DeSerializeObject::ProcessHdr
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
ERROR STACK 2
SYSTEM ERROR: A serious error has occurred in Repository
(c:\PROGRA~1\CSSPTEST\conplu0). Corrective action may be necessary.
Notify
your repository administrator.
Class: qqsp_ImplementationException
Error #: [1101, 198]
Detected at: qqrp_Repository::Fetch
Last TOOL statement: method
SalesDevelopment_NWC.DEVNotifyofTabSetCurrent
Error Time: Wed Dec 03 10:27:22
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1,
taskId =
[769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1.22]) in application
"ConPlus_GUI_cl0", pid 172 on node ISD42 in environment Edge.
SYSTEM ERROR: Could not read record (64,74615) from repository data file.
Header is corrupt.
Class: qqsp_ImplementationException
Error #: [1106, 612]
Detected at: qqbt_BtreeAccess::FetchDataFileRecord
Error Time: Wed Dec 03 10:27:22
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1,
taskId =
[769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1.22]) in application
"ConPlus_GUI_cl0", pid 172 on node ISD42 in environment Edge.
Technote 11225 Don't reparent mapped Widgets between UserWindows at
runtime
It is sometimes tempting to unparent a widget from one UserWindow and
reparent
it into another at runtime. However, this can cause crashes if the widget
(or
its decendants) are "mapped" to data. Here's why...
Suppose you have two UserWindows, UW1 and UW2. UW1 contains a DataField
(DF1)
which is mapped to a TextData. UW2 contains a RadioList (RL2) which is
mapped to
a scalar Integer. At compile time, every mapped attribute is internally
assigned
a "Map ID" (a small integer) which is used to tie the Widget to its
corresponding attribute. These Map IDs are used by the Widget to look up a
pointer to their data in a "Map" which is maintained by the UserWindow.
Each
UserWindow is assumed be to independent of the others, so there is nothing
wrong
with Widgets in different UserWindows being assigned the same Map IDs.
In
this
case, let's assume that DF1 and RL2 both got assigned the same Map ID of
3. No
problem so far, since each lives in a separate UserWindow with a separate
map.
Now suppose at runtime the application "detaches" or unparents DF1 from
its
UserWindow and reparents it somewhere into UW2. When it comes time for DF1
to
paint itself the Display System it must ask the Runtime System for the
value of
DF1's mapped attribute. To do that it says "give me the value of the
TextData
for DF1. You'll find it in the Map for this UserWindow (UW1), and its Map
ID is
3". When the runtime system goes to do this it expects to find a TextData
in
this "slot" of the map, but instead it picks up the integer which is
mapped to
RL2. At best this leads to bad data being returned; more likely you get a
segfault and a crash.
If DF1 was not a mapped attribute (say, a Rectangle) there would be no
problem
because there is no data mapped to a Rectangle. If instead of moving DF1
you
created a brand new DataField on the fly there would be no problem,
because the
dynamic DataField would not have any Map ID and so couldn't conflict with
any
IDs in UW2.
So how do you solve this problem? This is exactly what Nested Windows are
all
about. While you can't move DF1 into the middle of UW2, you can nest
UW1.
This
works because UW1 brings its map with it, and when you access DF1 it knows
to
look up its value in UW1's map.
UserWindows are intended to be the "unit of compilabilty" that can be
nested
inside other UserWindows. It is dangerous to "transplant" anything from
inside
one UserWindow into another at runtime.
(Note that you can't avoid this problem by cloning DF1 because the MapID
gets
copied along with it, and the clone will fail in the same way.)
Further details explained in related technote 12448 'Sudden client
partition
crashes at runtime.'
Technote 12448 Sudden client partition crashes at runtime
Scenario : You have two UserWindows, A and B. When Window A starts up, it
instantiates an instance of B and reparents some component of B into A's
window
hierarchy.
This is not allowed and almost always leads to an error at best or at
worse a
segmentation fault.
Here's why :
When you compile a UserWindow in Forte, each "mapped attribute" (whether a
form
element or menu element) is assigned an internal ID which represents an
offset into
that UserWindow's table of mapped attributes. This offset is only valid
in the
context of the UserWindow in which it was compiled. If you detach a
FieldWidget or
MenuWidget from one compiled Window ("tmpMenu" for example) and then
parent
into another compiled window ("tmpWindow") the internal ID comes with it.
When Forte tries to make use of that copied widget it uses the ID as an
offset
into tmpWindow's table of mapped attributes. But that copied offset is
meaningless in the context of tmpWindow's table, so you get some kind off
error.
In this case it found that the data type of the variable in the slot
wasn't
what
was expected. But you might even index off the end of the table and get a
segmentation fault.
There is nothing to prevent you from dynamically creating menu items and
adding
them to a window at runtime; that will work fine. Although of course you
can't
access them via mapped attributes, since those can only be created at
compile time.
But you are not allowed to reparent a widget from one compiled UserWindow
into
the hierarchy of another.
More information may be found in technote 11225 'Don't reparent mapped
Widgets
between UserWindows at runtime'.
Possible errorstacks seen at runtime instead of a complete crash or
segmentation
violation while you are illegally reparenting a widget or menuitem between
windows
at runtime:
Map::SetSubjectData: Invalid conversion from map type 0 to subject type 22
SYSTEM ERROR: Bad parameter at location 3 in method
qqrt_MapClassAccess::ProcessSubjectData.
Class: qqsp_Exception
Error #: [1001, 381]
Detected at: qqrt_MapClassAccess::ProcessSubjectData at 3
Error Time: Wed Aug 09 13:03:57
Exception occurred (locally) on partition "testproject_CL0_Client",
(partitionId = D4914A10-36C1-11D4-91B3-419AA33BAA77:0x208:0xd,
taskId =
[D4914A10-36C1-11D4-91B3-419AA33BAA77:0x208:0xd.68]) in application
"FTLaunch_cl0", pid 672 on node ONEWAY in environment Audi3M2Env.
At 13:14 26.09.00 -0400, Adamek, Zenon wrote:
Hi,
It is the unfixed defect 53398. Please contact Forte support.
Zenon
-----Original Message-----
From: Brenda Cumming [SMTP:brenda_cummingtranscanada.com]
Sent: Tuesday, September 26, 2000 1:15 PM
To: Forte User group
Subject: (forte-users) 3J=>3M new to me error
Hi,
We are in the process of going from 3J1 to 3.0.M.2, and I am getting
this error that I am unfamiliar with on a GUI that works fine in 3J.
It
does not happen all the time, and I have been unable to establish the
pattern that kicks it off. Has anyone seen this before?
PS- this error is not occurring in the deployed (non-compiled) app,but
when I am running locally from my workspace.
SYSTEM ERROR: Bad parameter at location 6 in method
qqrt_MapClassAccess::ProcessSubjectData.
Class: qqsp_Exception
Error #: [1001, 381]
Detected at: qqrt_MapClassAccess::ProcessSubjectData at 6
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2,
taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Can't find scope 20070 for a class.
Class: qqsp_Exception
Error #: [201, 11]
Detected at: qqlo_ClassTableLoadScope at 1
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Because of a prior error, your workspace was set to
read-only to prevent the application from attempting to write to the repository.
The repository and work you have saved to the repository are safe. If
your
workspace contains unsaved work, you may use the following procedure
to save this work. First, export the changed components. Then, shut down and
restart this application and reopen this workspace in read-write mode.
Finally, import the changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 695]
Detected at: qqrp_Session::IsDistributed
Last TOOL statement: method PPMeasWin.
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Internal Error attempting to deserialize element
(64,120684) (fetch bitmask is 0x20). Your workspace is now read-onlyto
prevent
the application from attempting to write to the repository. The
repository
and work you have saved to the repository are safe. If your workspace
contains unsaved work, you may use the following procedure to savethis
work.
First, export the changed components. Then, shut down and restart this
application and reopen this workspace in read-write mode. Finally, import the
changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 61]
Detected at: qqrp_LogicalSession::MaterializeObject
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Recursive Deserialization attempted, Internal Error!
Class: qqsp_UsageException with ReasonCode: SP_ER_INVALIDSTATE
Error #: [301, 231]
Detected at: qqsp_DeSerializeDriver::Run at 1
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in anew
email the word: 'Unsubscribe' to:forte-users-requestlists.xpedior.com
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.comHi Thomas,
Thanks for your email but I think it will be interesting for Brenda not me.
It is exactly what I have expected from Forte Support: detailed information
about bugs and workarounds. But what I cannot understand is that #53398 was
released without any information about possible reasons for this problem or
suggested workarounds. My first reaction after reading this bugreport was to
open a new case at CallCenter to get more information about it. Please
release more information with your bug reports !
Regards
Zenon Adamek
Information Services
Senior Programmer Analyst
Tel: 905 712-1084 ext. 3628
Fax: 905 712-6709
E-mail: zadamekpurolator.com
-----Original Message-----
From: Thomas Degen - Sun Germany Forte Tools - Bonn
[SMTP:thomas.degensun.com]
Sent: Wednesday, September 27, 2000 9:49 AM
To: Adamek, Zenon
Cc: 'Brenda Cumming'; Forte-userslists.xpedior.com
Subject: RE: (forte-users) 3J=>3M new to me error
Hi Zenon,
bug #53398 is not a bug which will likely get fixed, it's an informational
bugreport.
You might see an errorstack like Brenda has reported (and described in
informational
bugreport #53398) probably when you are doing something illegal that is
possible
via Forte Tool but Forte is not trapping it for performance reasons. Hence
you will see
the error coming from your illegal operation only at runtime, probably
only
while
running interpreted in the Forte IDE, but in worst case it might be even a
segmentation
violation.
Technotes 12448 'Sudden client partition crashes at runtime' and 11225
'Don't reparent
mapped Widgets between UserWindows at runtime' explain this matter . See
attached.
But maybe Brenda is much more experiencing a problem as described by Forte
Technote 11398 'Read Only Workspace Errors using ListViews or ActiveX
control'
that might get easily resolved via setting of FORTE_YIELD_THROTTLE=0.
Good Luck and Best Regards !
BTW: I've logged bug #53398, so I've felt responsible to explain its real
background.
Thomas
Thomas Degen
Sun Microsystems - Forte Tools
Forte CTE & Sustaining Group
Technical Support Germany
tel.:+49.228/91499-50
MailTo:thomas.degensun.com
Technote 11398 Read Only Workspace Errors using ListViews or ActiveX
control
SCENARIO:
Getting some unusual interpreter errors that result in an error stating
that
the workspace has been set to read only. Please see Enclosures for the
two
most common error stacks that have been encountered. The abbreviated
versions of the errors are:
- Can't read record (record size = -1)
- Id in index does not match id in record header in data file
- Recursive deserialization attempted.
- Unknown Mark type in deserialization
- Could not read record (64,74615) from repository data file.
Header
is corrupt.
These errors can be happening in either the development environment when
running from one of the development workshops, or with the deployed
application.
The bug outlined in this Technote may be the culprit if the errors above
are
seen when running a client on Windows NT or Motif and the user interface
incorporates ActiveX controls or ListView/TreeView widgets.
CAUSE:
Basically what is happening is that in rare circumstances Forte may invoke
a
nested copy of the interpreter while the first interpreter has yielded.
This
is not a problem in and of itself, but in the case where the original
interpreter was in the middle of a repository fetch when it yielded, and
the second interpreter needs to fetch code as well, we will get one of the
errors listed above, depending on the exact timing. The reason for the
errors is that the repository code at this level is thread-safe but not
re-entrant. It is protected by a mutex that is already owned by the
current task. Which, given the scenario outlined here, where the two
interpreters are running inside of the same task, results in the nested
interpreter being allowed to change data out from under the first.
While for every fetch one or more calls to WindowSystem.Yield will be made
(this is there to prevent the semblance of system lock-up on Win 3.1,
where
Yield is the only way other applications can be allowed to run), there is
a parameter which controls how often to actually yield, which by default
is
set to one out of every 100 calls. This is the reason the problem is
intermittent--you need a yield to occur during a repository fetch
which starts another interpreter which also needs to fetch code from
disk.
The reason this has only surfaced recently is that the nested interpreter
scenario can only happen in 2 cases that we know of:
- ActiveX controls which respond to events/Windows messages
- Outline fields/ListViews with column(s) mapped to virtual
attributes
In all other normal cases, the yield can process the message (typically a
paint message) without starting another interpreter, so regardless of
whether
the first interpreter yielded during a repository operation or not, there
is
no conflict.
SOLUTION:
The workaround is to prevent yields altogether by setting the
FORTE_YIELD_THROTTLE environment variable equal to 0 in the client's
environment. This should have no detrimental effects since the yield code
is in place solely for Windows 3.1x clients.
ERROR STACK 1
SYSTEM ERROR: Because of a prior error, your workspace was set to
read-only to
prevent the application from attempting to write to the repository. The
repository and work you have saved to the repository are safe. If your
workspace
contains unsaved work, you may use the following procedure to save this
work.
First, export the changed components. Then, shut down and restart this
application and reopen this workspace in read-write mode. Finally, import
the
changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 695]
Detected at: qqrp_Session::GetObjectById
Last TOOL statement: method EFWindowController.EFEventLoop
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
The remainder of the Error Manager stack is:
SYSTEM ERROR: Internal Error attempting to deserialize element (64,67470)
(fetch
bitmask is 0x20). Your workspace is now read-only to prevent the
application
from attempting to write to the repository. The repository and work you
have
saved to the repository are safe. If your workspace contains unsaved work,
you
may use the following procedure to save this work. First, export the
changed
components. Then, shut down and restart this application and reopen this
workspace in read-write mode. Finally, import the changed components and
save
your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 61]
Detected at: qqrp_LogicalSession::MaterializeObject
Last TOOL statement: method EFTabManagerNew.EFNoteBookHandler
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
SYSTEM ERROR: Unknown Mark type in deserialization.
Class: qqsp_ImplementationException
Error #: [1101, 34]
Detected at: qqrp_DeSerializeObject::ProcessHdr
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
ERROR STACK 2
SYSTEM ERROR: A serious error has occurred in Repository
(c:\PROGRA~1\CSSPTEST\conplu0). Corrective action may be necessary.
Notify
your repository administrator.
Class: qqsp_ImplementationException
Error #: [1101, 198]
Detected at: qqrp_Repository::Fetch
Last TOOL statement: method
SalesDevelopment_NWC.DEVNotifyofTabSetCurrent
Error Time: Wed Dec 03 10:27:22
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1,
taskId =
[769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1.22]) in application
"ConPlus_GUI_cl0", pid 172 on node ISD42 in environment Edge.
SYSTEM ERROR: Could not read record (64,74615) from repository data file.
Header is corrupt.
Class: qqsp_ImplementationException
Error #: [1106, 612]
Detected at: qqbt_BtreeAccess::FetchDataFileRecord
Error Time: Wed Dec 03 10:27:22
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1,
taskId =
[769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1.22]) in application
"ConPlus_GUI_cl0", pid 172 on node ISD42 in environment Edge.
Technote 11225 Don't reparent mapped Widgets between UserWindows at
runtime
It is sometimes tempting to unparent a widget from one UserWindow and
reparent
it into another at runtime. However, this can cause crashes if the widget
(or
its decendants) are "mapped" to data. Here's why...
Suppose you have two UserWindows, UW1 and UW2. UW1 contains a DataField
(DF1)
which is mapped to a TextData. UW2 contains a RadioList (RL2) which is
mapped to
a scalar Integer. At compile time, every mapped attribute is internally
assigned
a "Map ID" (a small integer) which is used to tie the Widget to its
corresponding attribute. These Map IDs are used by the Widget to look up a
pointer to their data in a "Map" which is maintained by the UserWindow.
Each
UserWindow is assumed be to independent of the others, so there is nothing
wrong
with Widgets in different UserWindows being assigned the same Map IDs.
In
this
case, let's assume that DF1 and RL2 both got assigned the same Map ID of
3. No
problem so far, since each lives in a separate UserWindow with a separate
map.
Now suppose at runtime the application "detaches" or unparents DF1 from
its
UserWindow and reparents it somewhere into UW2. When it comes time for DF1
to
paint itself the Display System it must ask the Runtime System for the
value of
DF1's mapped attribute. To do that it says "give me the value of the
TextData
for DF1. You'll find it in the Map for this UserWindow (UW1), and its Map
ID is
3". When the runtime system goes to do this it expects to find a TextData
in
this "slot" of the map, but instead it picks up the integer which is
mapped to
RL2. At best this leads to bad data being returned; more likely you get a
segfault and a crash.
If DF1 was not a mapped attribute (say, a Rectangle) there would be no
problem
because there is no data mapped to a Rectangle. If instead of moving DF1
you
created a brand new DataField on the fly there would be no problem,
because the
dynamic DataField would not have any Map ID and so couldn't conflict with
any
IDs in UW2.
So how do you solve this problem? This is exactly what Nested Windows are
all
about. While you can't move DF1 into the middle of UW2, you can nest
UW1.
This
works because UW1 brings its map with it, and when you access DF1 it knows
to
look up its value in UW1's map.
UserWindows are intended to be the "unit of compilabilty" that can be
nested
inside other UserWindows. It is dangerous to "transplant" anything from
inside
one UserWindow into another at runtime.
(Note that you can't avoid this problem by cloning DF1 because the MapID
gets
copied along with it, and the clone will fail in the same way.)
Further details explained in related technote 12448 'Sudden client
partition
crashes at runtime.'
Technote 12448 Sudden client partition crashes at runtime
Scenario : You have two UserWindows, A and B. When Window A starts up, it
instantiates an instance of B and reparents some component of B into A's
window
hierarchy.
This is not allowed and almost always leads to an error at best or at
worse a
segmentation fault.
Here's why :
When you compile a UserWindow in Forte, each "mapped attribute" (whether a
form
element or menu element) is assigned an internal ID which represents an
offset into
that UserWindow's table of mapped attributes. This offset is only valid
in the
context of the UserWindow in which it was compiled. If you detach a
FieldWidget or
MenuWidget from one compiled Window ("tmpMenu" for example) and then
parent
into another compiled window ("tmpWindow") the internal ID comes with it.
When Forte tries to make use of that copied widget it uses the ID as an
offset
into tmpWindow's table of mapped attributes. But that copied offset is
meaningless in the context of tmpWindow's table, so you get some kind off
error.
In this case it found that the data type of the variable in the slot
wasn't
what
was expected. But you might even index off the end of the table and get a
segmentation fault.
There is nothing to prevent you from dynamically creating menu items and
adding
them to a window at runtime; that will work fine. Although of course you
can't
access them via mapped attributes, since those can only be created at
compile time.
But you are not allowed to reparent a widget from one compiled UserWindow
into
the hierarchy of another.
More information may be found in technote 11225 'Don't reparent mapped
Widgets
between UserWindows at runtime'.
Possible errorstacks seen at runtime instead of a complete crash or
segmentation
violation while you are illegally reparenting a widget or menuitem between
windows
at runtime:
Map::SetSubjectData: Invalid conversion from map type 0 to subject type 22
SYSTEM ERROR: Bad parameter at location 3 in method
qqrt_MapClassAccess::ProcessSubjectData.
Class: qqsp_Exception
Error #: [1001, 381]
Detected at: qqrt_MapClassAccess::ProcessSubjectData at 3
Error Time: Wed Aug 09 13:03:57
Exception occurred (locally) on partition "testproject_CL0_Client",
(partitionId = D4914A10-36C1-11D4-91B3-419AA33BAA77:0x208:0xd,
taskId =
[D4914A10-36C1-11D4-91B3-419AA33BAA77:0x208:0xd.68]) in application
"FTLaunch_cl0", pid 672 on node ONEWAY in environment Audi3M2Env.
At 13:14 26.09.00 -0400, Adamek, Zenon wrote:
Hi,
It is the unfixed defect 53398. Please contact Forte support.
Zenon
-----Original Message-----
From: Brenda Cumming [SMTP:brenda_cummingtranscanada.com]
Sent: Tuesday, September 26, 2000 1:15 PM
To: Forte User group
Subject: (forte-users) 3J=>3M new to me error
Hi,
We are in the process of going from 3J1 to 3.0.M.2, and I am getting
this error that I am unfamiliar with on a GUI that works fine in 3J.
It
does not happen all the time, and I have been unable to establish the
pattern that kicks it off. Has anyone seen this before?
PS- this error is not occurring in the deployed (non-compiled) app,but
when I am running locally from my workspace.
SYSTEM ERROR: Bad parameter at location 6 in method
qqrt_MapClassAccess::ProcessSubjectData.
Class: qqsp_Exception
Error #: [1001, 381]
Detected at: qqrt_MapClassAccess::ProcessSubjectData at 6
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2,
taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Can't find scope 20070 for a class.
Class: qqsp_Exception
Error #: [201, 11]
Detected at: qqlo_ClassTableLoadScope at 1
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Because of a prior error, your workspace was set to
read-only to prevent the application from attempting to write to the repository.
The repository and work you have saved to the repository are safe. If
your
workspace contains unsaved work, you may use the following procedure
to save this work. First, export the changed components. Then, shut down and
restart this application and reopen this workspace in read-write mode.
Finally, import the changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 695]
Detected at: qqrp_Session::IsDistributed
Last TOOL statement: method PPMeasWin.
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Internal Error attempting to deserialize element
(64,120684) (fetch bitmask is 0x20). Your workspace is now read-onlyto
prevent
the application from attempting to write to the repository. The
repository
and work you have saved to the repository are safe. If your workspace
contains unsaved work, you may use the following procedure to savethis
work.
First, export the changed components. Then, shut down and restart this
application and reopen this workspace in read-write mode. Finally, import the
changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 61]
Detected at: qqrp_LogicalSession::MaterializeObject
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Recursive Deserialization attempted, Internal Error!
Class: qqsp_UsageException with ReasonCode: SP_ER_INVALIDSTATE
Error #: [301, 231]
Detected at: qqsp_DeSerializeDriver::Run at 1
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in anew
email the word: 'Unsubscribe' to:forte-users-requestlists.xpedior.com
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com -
Is this a bug? What do I do?
Hi all,
I am running an update of a table with 2 columns from 9.2.0.8 to 8.1.7.4 over database link.
First column (number) is updated, but second appears to be NULL. ?!
I've tried to do it from 8.1.7 to 9.2, but with the same result.
Then I've tried to create a table on 8.1.7 side and insert data from 9.2 into it first, but .... same: NULL values for char colums.
Is it a bug?
What else can I try?
Thanks,
EugeneThanks all for replies.
This is the oddest thing and that is why I was asking you if it's a bug. It worked this time and you will laugh at me.
Here is what I've done:
============
9.2 DB
============
select * from v$version;
BANNER
Oracle9i Enterprise Edition Release 9.2.0.8.0 - Production
PL/SQL Release 9.2.0.8.0 - Production
CORE 9.2.0.8.0 Production
TNS for 32-bit Windows: Version 9.2.0.8.0 - Production
NLSRTL Version 9.2.0.8.0 - Production
desc macys_store_names;
Name Null? Type
PH00_PKT_CTL_NBR NOT NULL NUMBER(6)
STORE_NAME CHAR(25)
truncate table macys_store_names;
Table truncated.
select count(*) macys_rec_num
2 from phpick00@db817
3 where ph00_soldto like 'MACYS%'
4 and ph00_pkt_stat_flg = ' ';
MACYS_REC_NUM
1292
insert into macys_store_names
2 SELECT ph00_pkt_ctl_nbr,
3 substr(defa_cust_store_name,1,25) store_name
4 FROM sales_order A,
5 customer_store b,
6 (
7 select ph00_pkt_ctl_nbr,
8 '81' business_unit_id,
9 SUBSTR(ph00_order,1,1) sales_order_prefix,
10 LTRIM(SUBSTR(REPLACE((ph00_order||ph00_order_sfx),' ',''),2),0) sales_order_numb
er
11 from phpick00@db817
12 where ph00_soldto like 'MACYS%'
13 and ph00_pkt_stat_flg = ' '
14 ) c
15 WHERE A.business_unit_id = b.business_unit_id AND
16 A.customer_id = b.customer_id AND
17 A.customer_store_id = b.customer_store_id AND
18 a.business_unit_id = c.business_unit_id
19 and a.sales_order_prefix = c.sales_order_prefix
20 and a.sales_order_number = c.sales_order_number;
1292 rows created.
commit;
Commit complete.
select * from macys_store_names where rownum < 10;
PH00_PKT_CTL_NBR STORE_NAME
567384 Fort Steuben
567385 Fort Steuben
567386 Chesterfield MO
567387 Chesterfield MO
567388 Mid Rivers
567389 Mid Rivers
567390 White Oaks
567391 White Oaks
567392 Market Place IL
9 rows selected.
update phpick00@db817 a
2 set ph00_mark_for = (select store_name
3 from macys_store_names b
4 where a.ph00_pkt_ctl_nbr = b.ph00_pkt_ctl_nbr)
5 ,ph00_lm_user_id = 'MACYS_STOR'
6 ,ph00_dlm = sysdate
7 where ph00_pkt_ctl_nbr in
8 (select ph00_pkt_ctl_nbr from macys_store_names);
1292 rows updated.
commit;
============
8.1.7 DB
============
select * from v$version;
BANNER
Oracle8i Enterprise Edition Release 8.1.7.4.1 - Production
PL/SQL Release 8.1.7.4.0 - Production
CORE 8.1.7.2.1 Production
TNS for 32-bit Windows: Version 8.1.7.4.0 - Production
NLSRTL Version 3.4.1.0.0 - Production
select ph00_pkt_ctl_nbr, ph00_mark_for
2 from phpick00
3 where ph00_pkt_ctl_nbr in
4 (select ph00_pkt_ctl_nbr from macys_store_names@db92)
5 and rownum < 10
6 ;
PH00_PKT_CTL_NBR PH00_MARK_FOR
566781 Queens
566782 Queens
566783 Brooklyn
566784 Brooklyn
566785 Herald Square
566786 Herald Square
566787 Westfarms Mall
566788 Westfarms Mall
566789 Manhasset
9 rows selected.
Thanks,
Eugene
Edited by: epipko on Oct 19, 2009 10:40 AM
Edited by: epipko on Oct 19, 2009 10:44 AM -
Testing in Forte: Good News :-)
Hi
The purpose of this message is to address some inaccuracies in the attached
message regarding testing tools. I thought I would share with you all what
I found out about testing tools that work with Forte.
I heard back from Forte users about two testing tools:
1) Mercury LoadRunner / WinRunner etc.
2) ClassIQ's product called IQTest
Mercury
I spoke with a Mercury representative today who listed for me several sites
which are successfully using Forte with Mercury (one of these sites is even
located here in Australia!). The problems described in the attached
message or accurate; however, the workarounds are documented and easy to
understand.
You can use Mercury today with Forte.
In addition, Mercury has been working for several months now on an even
tighter integration with Forte. This project has been extremely
successful. There is at least one Forte site in the USA which is using
this Forte/Mercury integrated product. According to the Mercury rep, the
Mercury/Forte tighter integration is now in beta testing and should be
production in May/June 1997. This information was verified by my contacts
at Forte HQ. If any of you need more detailed information than this please
contact me or your Mercury representative.
ClassIQ
ClassIQ currently has a small number of sites using its testing tools which
are written in Forte. Needless to say, ClassIQ is very tightly integrated
with the Forte environment. If you would like to know more about ClassIQ
contact Joe Burns at 105210,[email protected].
I am sure there are many other people using other testing tools with
Forte....these are just the two I have heard about in the initial responses
to my query. I would love to hear about other testing tools which work
well with Forte.
Regards,
Eric
At 11:19 AM 2/19/97 +0530, you wrote:
Hi,
We evaluated quite a few test tools in relation to the forte
environment. All of them have the same problem : The inability to
correctly map Forte widgets. Most of them cannot recognise
Outlinefields, ArrayFields etc. Even if they do recognise a forte widget
only basic properties like the size of the widget, its position on the
screen etc. are recorded. Data contents of the widget are not
recognized.
To clarify the above points : Given a screen with a TextData widget, you
can record and playback this sequence without any problems with most
Test tools :- Position the mouse on the widget, Type 'Testing' .
Ideally, the TextData widget should have a property 'Content' or 'Value'
(different test tools call it differently) which will have the value
'Testing'. In case of forte this does not happen. What is recorded are
the low level mouse movements or keyboard strokes. The position on the
screen where the value is typed is recorded and played back.
Low level recording maybe acceptable in some circumstances but say - you
have a widget which gets populated by a database query. How will you
test the values displayed ?
Some of the test tools are customizable i.e. you can actually create a
widget class of your own and try to map it to a recognized (by the Tool)
widget class. This will be a time consuming process with a great deal of
trial and error and no guarantees of success.
If the sole objective is navigate through screens and record and
playback, then most of the automated test tools work. If you want to
make full use of a test tools capabilities and want to go further and
intelligently record and playback, most test tools have very very
limited use.
Discussions with Test tool vendors have revealed the following :
- Forte has not released a Test API to any particular vendor or the
market at large
- Forte implementation sites are at the moment too few for any test tool
vendor to invest in Research and Development and come out with a Test
API.
So as it goes the chances of a fully compatible Forte test tool in the
near future are remote.
Forte's own AutoTester project has a limited usage. My own evaluation is
that it cannot be used for big sized implementations. Along with other
limitations, test management facilities that are particularly relevant
for big sized implementations simply don't exist with AutoTester.
The only product in the market that is Forte specific and is more a
testing Framework than a tool is TestIQ from ClassIQ. I am keen to get
information about TestIQ from any of its implementation sites. Again I
am not sure about its test management capabilities.
Hope the information helps,
Parvathi Iyer,
[email protected]
From: David Campbell[SMTP:[email protected]]
Sent: Tuesday, February 18, 1997 2:08PM
To: [email protected]
Subject: Development tools
Hi all,
We are about to embark on a sizable Forte development and are interested
in hearing from anybody who has successfully used automated test tools
with Forte. Also, does anybody know of a problem tracking tool that can
be linked to the Forte source repository for the purpose of tracking the
status software bugs, fixes etc.
Thanks,
David Campbell
System Consultant
CSC Australia
From: [email protected][SMTP:[email protected]]
Sent: Tuesday, February 18, 1997 11:58 PM
To: [email protected]
Subject: Automated test tools
I've read about Capture/Replay and played with the AutoTester project a
little. I'm curious as to the experiences that developers have had with
using these tools to automate testing of GUI applications. Has anyone
actually deployed an application that successfully uses these tools? How
does it compare against other automated test tools?
One limitation that I see with using Capture/Replay is that any non-Forte
client interfacing with my Forte code would not be able to use this
mechanism to perform its auto testing. Also, while playing with the
AutoTester I actually got a playback which was slightly different than what
I did while doing the capture.
Thanks,
Jim Hancock
[email protected]
--_|\ Eric Gold
/ \ Technical Director
\_.--._* Forte Australia
v Voice: 61-2-9926-1403
Fax: 61-2-9926-1401
http://www.forte.com
He is happiest who advances more gradually to greatness.
-- Adam SmithThanks for the news Nancy!
-
RE: (forte-users) Named Anchored Obj-EnvironmentFailover
I did some playing around with this stuff as well. I can tell you a few
things.
1) The search path option of connected environments only works for SO's, not
for named anchors.
2) When EnvA creates a directory "/glob", which contains object "obj1", then
EnvA owns directory "/glob". Even after restarting environments. If EnvB
tries to add a subdirectory to "/glob" or inserts its own objects into this
path, then the situation becomes unstable. It doesn't immediately produce an
error, but things go wrong anyway. Is this a bug or expected behaviour? I
don't know. I just learned not to do this. Every environment must place it's
named anchors in it's own tree. Directories can't be shared.
3) I think the relative name "glob/obj1" should work, but only if you set
the ObjectLocationMgr to start looking at the root. Default, it will start
looking in it's own environment basepath. But I don't have any experience
with this.
Pascal Rottier
Atos Origin Nederland (BAS/West End User Computing)
Tel. +31 (0)10-2661223
Fax. +31 (0)10-2661199
E-mail: Pascal.Rottiernl.origin-it.com
++++++++++++++++++++++++++++
Philip Morris (Afd. MIS)
Tel. +31 (0)164-295149
Fax. +31 (0)164-294444
E-mail: Rottier.Pascalpmintl.ch
-----Original Message-----
From: Master Programmer [mailto:masterprghotmail.com]
Sent: Monday, January 08, 2001 11:13 PM
To: forte-userslists.xpedior.com
Subject: (forte-users) Named Anchored Obj-Environment Failover
Hi to all,
We connect from EnvA to EnvB giving the user directory parameter as / and
set the Environment Search Path
as EnvA:EnvB. From both environments we start and register
'/glob/obj1' named anchored objects with the same name.
From a client we connect to EnvA and bind to'/glob/obj1' when we shutdown EnvA partition it fails-over to
EnvB. And then we restart EnvA partition. We restart/rebind the client and
try to use object. We see that it is using the EnvB object.
Although we started the primary environment object again.
It is not using the search path. Once we shutdown secondary environment
it starts using primary environment object.
When we try to use relative path when we are binding the object
First parameter ('glob/obj1') No first slash. Trying 3rd parameter
for bind function or just using environment search path, Is is not able to
find the object. From nsls command I figured out that
under the root directory
/forte/UUID of ENVA/node
/site
/UUID of ENVB
/glob/obj1
names are available. When we use relative path (without slash)
is it trying to find /glob/obj1 under the /forte/UUID of ENVA
but we are registering the name under the root.
What is the reason of this odd behaviour or is this a bug?
Any answer will be appreciated,
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.comI did some playing around with this stuff as well. I can tell you a few
things.
1) The search path option of connected environments only works for SO's, not
for named anchors.
2) When EnvA creates a directory "/glob", which contains object "obj1", then
EnvA owns directory "/glob". Even after restarting environments. If EnvB
tries to add a subdirectory to "/glob" or inserts its own objects into this
path, then the situation becomes unstable. It doesn't immediately produce an
error, but things go wrong anyway. Is this a bug or expected behaviour? I
don't know. I just learned not to do this. Every environment must place it's
named anchors in it's own tree. Directories can't be shared.
3) I think the relative name "glob/obj1" should work, but only if you set
the ObjectLocationMgr to start looking at the root. Default, it will start
looking in it's own environment basepath. But I don't have any experience
with this.
Pascal Rottier
Atos Origin Nederland (BAS/West End User Computing)
Tel. +31 (0)10-2661223
Fax. +31 (0)10-2661199
E-mail: Pascal.Rottiernl.origin-it.com
++++++++++++++++++++++++++++
Philip Morris (Afd. MIS)
Tel. +31 (0)164-295149
Fax. +31 (0)164-294444
E-mail: Rottier.Pascalpmintl.ch
-----Original Message-----
From: Master Programmer [mailto:masterprghotmail.com]
Sent: Monday, January 08, 2001 11:13 PM
To: forte-userslists.xpedior.com
Subject: (forte-users) Named Anchored Obj-Environment Failover
Hi to all,
We connect from EnvA to EnvB giving the user directory parameter as / and
set the Environment Search Path
as EnvA:EnvB. From both environments we start and register
'/glob/obj1' named anchored objects with the same name.
From a client we connect to EnvA and bind to'/glob/obj1' when we shutdown EnvA partition it fails-over to
EnvB. And then we restart EnvA partition. We restart/rebind the client and
try to use object. We see that it is using the EnvB object.
Although we started the primary environment object again.
It is not using the search path. Once we shutdown secondary environment
it starts using primary environment object.
When we try to use relative path when we are binding the object
First parameter ('glob/obj1') No first slash. Trying 3rd parameter
for bind function or just using environment search path, Is is not able to
find the object. From nsls command I figured out that
under the root directory
/forte/UUID of ENVA/node
/site
/UUID of ENVB
/glob/obj1
names are available. When we use relative path (without slash)
is it trying to find /glob/obj1 under the /forte/UUID of ENVA
but we are registering the name under the root.
What is the reason of this odd behaviour or is this a bug?
Any answer will be appreciated,
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com -
Another bug in sun one studio?
is this another bug in sun one studio or something else.
i have set the author to a different name through
tools -> options -> java sources
but when i create session beans or cmp beans, it uses the previous name.
however java main classes display the new nameThis looks like a bug to me. I didn't see anything in the bug database that was similar, so I would suggest that you file a bug at:
http://java.sun.com/webapps/bugreport/
using:
Category: Sun Java Studio, Sun ONE Studio, Forte for Java
SubCat: EJB Components -
Re: Crystal Reports 5.0 (32-Bit) and Forte 2.0H16 on NT3.51
Dear Silke,
Crystal's default for identifying a table in the report design is
<schema>.<table>. You can change that by going to the Database Location menu
item and cutting the schema prefix off. You should do that for every table in
the report. The PESetNthTableLogOnInfo function will, I believe, not change
the schema prefix of a table, since it assumes you really want that schema,
i.e., as an override. Also, if you are using the propagateAcrossAllTables
feature of the function make sure that every table has the schema prefix cut
off, otherwise those tables will be skipped, since the propagate feature applies
to all other similar tables only. For example, some of the tables could be
Sybase, etc.
I believe you can change the default behaviour of the CR Report Designer in the
File->Preferences menu, so that when reports are designed the schema prefix is
not automatically attached.
I have compiled some guidelines on designing reports to make them work properly
with Forte. I will try to send them to you next week. Crystal Reports and its
C API are a good product, and you will get good performance once the report
design is set up properly.
Yours very sincerely, John Hodgson.
Schulte, Silke (DVD) wrote:
The problem seems to be, that Crystal stores the database name in the
report. If you want to change the database you have to develop your
report new, although you give the connection-information via the API.
The hotline from Crystal told us, when using subreports you have to use
the PESetNthTableLogOnInfo and to go through all the subreports and
change the connect-string.
Our experience is, you have to do both: change the report and call the
other function for the subreports.
Thank you very much for all the tips.
Regards
Silke Schulte
Union-Investment, Frankfurt / Main, Germany
e-mail: [email protected]
From: Ajith Kallambella M[SMTP:[email protected]]
Sent: Mittwoch, 23. September 1998 15:17
To: [email protected]; ForteUsers; [email protected]
Subject: RE: Crystal Reports 5.0 (32-Bit) and Forte 2.0H16 on NT
3.51
Hi There,
Crystal reports stores Database name as a hard-coded
value in the
report template. So if you have to use an other
database, you will
have to open the report template and modify the
database name. I
think this is why you are getting Crystal API error.
Hope this helps!
Ajith Kallambella M
Forte systems Engineer,
International Business Corporation.
Hello,
I wonder if we have a similar problem.
We are using Crystal Reports 5 and Forte 3.0.F.2. For
the interface
between Forte and Crystal we have in Forte a Lib using
C-wrappering to
the C-API of Crystal.
We have developed a report on a database in our
development-environment. This report comes up with data
and works
correct. It's no different if we have saved the report
in Crystal with
data or without.
If we want to use the same report on another database
in our
test-environment the window from crystal reports comes
up and when
starting there is an error from the Crystal API
function.
Both environments use the same version of an Oracle
Database and are on
Open VMS. The client for the test is in this case
always the same.
From the C-API we use the method PEStartPrintJob after
we have specified
the rest for the report.
Is there a possibility that this is the same error you
mentioned? Or do
you have any other ideas?
Any help is appreciated.
Regards
Silke Schulte
Union-Investment Frankfurt (Germany)
email: [email protected]
From: Katie Carty[SMTP:[email protected]]
Reply To: Katie Carty
Sent: Montag, 21. September 1998 19:14
To: 'Tim Hagemann'; [email protected]
Subject: RE: Crystal Reports 5.0 (32-Bit) and Forte2.0H16 on NT
3.51
Tim,
You need to upgrade to CrystalReports 6.0. There isa bug in the
interaction between Forte and CrystalReports 5.0 (Idon't know on
which side the bug resides, but I think that it is onthe Crystal end,
since the problem occurs both through C-wrapperingand OLE
interaction), which does not allow you to invoke thePrintReport
method unless you have saved data with the report.
As far as I know, there is no workaround, and theonly solution is to
upgrade to CrystalReports 6.0.
FYI, there is no ActiveX control supplied withCrystalReports 5.0 -
you are actually using standard OLE integration.
Hope this helps...
Regards,
-Katie
-----Original Message-----
From: Tim Hagemann [SMTP:[email protected]]
Sent: Monday, September 21, 1998 11:27 AM
To: [email protected]
Subject: Crystal Reports 5.0 (32-Bit) and Forte2.0H16 on NT 3.51
Hi Forte-User !
We got a big problem here using the crystal active-xcontrol. On my
windows-nt 4.0 machine (with
crystal reports installed completely) all works well.On our test
machine (with only the crystal ActiveX
installed), the Forte runtime shuts down afterinvoking a special
method of the ocx (PrintReport).
The cause for shutting down (no stacktrace orsomething like that) is
a generated c++ exception in crystal -
but we don't know the cause of this exception.
Has anyone made the control work under nt 3.51 ? Doesanybody know
(exactly) what dll's we'll have
to use ?
TIA,
Tim Hagemann
Tim Hagemann
Ascom GmbH Email:
[email protected]
Charlottenburger Allee 61 Phone: +49241 96806 273
D-52068 Aachen Fax: +49241 96806 225
>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>-
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>Dear Silke,
Crystal's default for identifying a table in the report design is
<schema>.<table>. You can change that by going to the Database Location menu
item and cutting the schema prefix off. You should do that for every table in
the report. The PESetNthTableLogOnInfo function will, I believe, not change
the schema prefix of a table, since it assumes you really want that schema,
i.e., as an override. Also, if you are using the propagateAcrossAllTables
feature of the function make sure that every table has the schema prefix cut
off, otherwise those tables will be skipped, since the propagate feature applies
to all other similar tables only. For example, some of the tables could be
Sybase, etc.
I believe you can change the default behaviour of the CR Report Designer in the
File->Preferences menu, so that when reports are designed the schema prefix is
not automatically attached.
I have compiled some guidelines on designing reports to make them work properly
with Forte. I will try to send them to you next week. Crystal Reports and its
C API are a good product, and you will get good performance once the report
design is set up properly.
Yours very sincerely, John Hodgson.
Schulte, Silke (DVD) wrote:
The problem seems to be, that Crystal stores the database name in the
report. If you want to change the database you have to develop your
report new, although you give the connection-information via the API.
The hotline from Crystal told us, when using subreports you have to use
the PESetNthTableLogOnInfo and to go through all the subreports and
change the connect-string.
Our experience is, you have to do both: change the report and call the
other function for the subreports.
Thank you very much for all the tips.
Regards
Silke Schulte
Union-Investment, Frankfurt / Main, Germany
e-mail: [email protected]
From: Ajith Kallambella M[SMTP:[email protected]]
Sent: Mittwoch, 23. September 1998 15:17
To: [email protected]; ForteUsers; [email protected]
Subject: RE: Crystal Reports 5.0 (32-Bit) and Forte 2.0H16 on NT
3.51
Hi There,
Crystal reports stores Database name as a hard-coded
value in the
report template. So if you have to use an other
database, you will
have to open the report template and modify the
database name. I
think this is why you are getting Crystal API error.
Hope this helps!
Ajith Kallambella M
Forte systems Engineer,
International Business Corporation.
Hello,
I wonder if we have a similar problem.
We are using Crystal Reports 5 and Forte 3.0.F.2. For
the interface
between Forte and Crystal we have in Forte a Lib using
C-wrappering to
the C-API of Crystal.
We have developed a report on a database in our
development-environment. This report comes up with data
and works
correct. It's no different if we have saved the report
in Crystal with
data or without.
If we want to use the same report on another database
in our
test-environment the window from crystal reports comes
up and when
starting there is an error from the Crystal API
function.
Both environments use the same version of an Oracle
Database and are on
Open VMS. The client for the test is in this case
always the same.
From the C-API we use the method PEStartPrintJob after
we have specified
the rest for the report.
Is there a possibility that this is the same error you
mentioned? Or do
you have any other ideas?
Any help is appreciated.
Regards
Silke Schulte
Union-Investment Frankfurt (Germany)
email: [email protected]
From: Katie Carty[SMTP:[email protected]]
Reply To: Katie Carty
Sent: Montag, 21. September 1998 19:14
To: 'Tim Hagemann'; [email protected]
Subject: RE: Crystal Reports 5.0 (32-Bit) and Forte2.0H16 on NT
3.51
Tim,
You need to upgrade to CrystalReports 6.0. There isa bug in the
interaction between Forte and CrystalReports 5.0 (Idon't know on
which side the bug resides, but I think that it is onthe Crystal end,
since the problem occurs both through C-wrapperingand OLE
interaction), which does not allow you to invoke thePrintReport
method unless you have saved data with the report.
As far as I know, there is no workaround, and theonly solution is to
upgrade to CrystalReports 6.0.
FYI, there is no ActiveX control supplied withCrystalReports 5.0 -
you are actually using standard OLE integration.
Hope this helps...
Regards,
-Katie
-----Original Message-----
From: Tim Hagemann [SMTP:[email protected]]
Sent: Monday, September 21, 1998 11:27 AM
To: [email protected]
Subject: Crystal Reports 5.0 (32-Bit) and Forte2.0H16 on NT 3.51
Hi Forte-User !
We got a big problem here using the crystal active-xcontrol. On my
windows-nt 4.0 machine (with
crystal reports installed completely) all works well.On our test
machine (with only the crystal ActiveX
installed), the Forte runtime shuts down afterinvoking a special
method of the ocx (PrintReport).
The cause for shutting down (no stacktrace orsomething like that) is
a generated c++ exception in crystal -
but we don't know the cause of this exception.
Has anyone made the control work under nt 3.51 ? Doesanybody know
(exactly) what dll's we'll have
to use ?
TIA,
Tim Hagemann
Tim Hagemann
Ascom GmbH Email:
[email protected]
Charlottenburger Allee 61 Phone: +49241 96806 273
D-52068 Aachen Fax: +49241 96806 225
>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>-
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/> -
Re: Forte and OrbixWeb call-back
We have created a business process manager (BPM) layer between our client GUI
and business model objects that supports Java call-in/call-out. This enables
switching out the Forte windows with Java windows for a web solution with
minimal code re-write.
We were able to get most functionality to work as per our design, which
included registering a call back function from a Java GUI in the BPM, but had
to make some sacrifices due to a Forte bug, at least under 3.0.D. We turned
in case #38434, detailing errors when we tried to fire a callback method with
parameters, example below ("callback" was the Java object passed in.)
method TestIIOPBackend.FireCallback(input message: Framework.string)
begin
if callback != nil then
task.part.logmgr.putline('Firing callback');
//WORKS
callback.CallMe();
//ERROR!
callback.CallMeString(message);
else
task.part.logmgr.putline('Callback not set');
end if;
end method;
This may have been fixed in 3.0.F, we found a way to work around it in our
design and haven't investigated since.
-DFR
Ngai* Stuart <[email protected]> on 01/20/98 09:14:28 AM
To: '[email protected]' <[email protected]> @ INTERNET
cc:
Subject: Forte and OrbixWeb call-back
Has anyone actually tried the tech note 11153 "Java call-in/call-out and
Forte
Anchored Objects"? I'm trying to verify the callback mechanism from
Forte to
an IIOP Java client. Thanks.
<<< Stuart Ngai (416)359-4306 [email protected] >>>
------ Message Header Follows ------
Received: from pebble.SageIT.com by notes.bsginc.com
(PostalUnion/SMTP(tm) v2.1.9c for Windows NT(tm))
id AA-1998Jan20.101336.1771.787915; Tue, 20 Jan 1998 10:13:36 -0600
Received: (from sync@localhost) by pebble.SageIT.com (8.6.10/8.6.9) id HAA03868
for forte-users-outgoing; Tue, 20 Jan 1998 07:25:41 -0800
Received: (from uucp@localhost) by pebble.SageIT.com (8.6.10/8.6.9) id HAA03862
for <[email protected]>; Tue, 20 Jan 1998 07:25:39 -0800
Received: from keeper.nesbittburns.ca(192.139.71.50) by pebble.sagesoln.com via
smap (V2.0)
id xma003860; Tue, 20 Jan 98 07:25:19 -0800
Received: from NesbittBurns.ca (tds223.nesbittburns.ca) by
keeper.NesbittBurns.ca (4.1/SMI-4.1)
id AA22591; Tue, 20 Jan 98 10:23:47 EST
Received: from nbtormail02.nesbittburns.ca by NesbittBurns.ca (5.x/SMI-SVR4)
id AA12961; Tue, 20 Jan 1998 10:26:54 -0500
Received: by nbtormail02.nesbittburns.ca with SMTP (Microsoft Exchange Server
Internet Mail Connector Version 4.0.995.52)
id <[email protected]>; Tue, 20 Jan 1998
10:27:52
-0500
Message-Id:
<c=CA%a=_%p=Nesbitt_Burns_In%[email protected]>
From: "Ngai, Stuart" <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Forte and OrbixWeb call-back
Date: Tue, 20 Jan 1998 10:27:39 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [email protected]
Precedence: bulk
Reply-To: "Ngai, Stuart" <[email protected]>Peggy,
1) Do you have experience with PowerBuilder and Forte' applications running at
the same time on the same (laptop) computer? Here I'm thinking
about any potential resource constraints? Memory Requirements?As log as you are using Win95 or NT you should not be concerned about WIN-resources. Memory depends more on what your 2 tier PB application requires than what your Forté would require.
Cheers,
Troels
Lindhard Forté Solutions
-----Original Message-----
From: Peggy Lynn Adrian [SMTP:[email protected]]
Sent: Thursday, January 15, 1998 10:31 PM
To: [email protected]
Subject: Forte and Powerbuilder Experience Needed
I sent this query to Forte support but maybe someone out there can help me
with practical experience
with the following?
---------------------- Forwarded by Peggy Lynn Adrian/AM/LLY on 01/15/98 04:30
PM ---------------------------
Peggy Lynn Adrian
01/14/98 03:55 PM
To: [email protected]
cc: Peggy Lynn Adrian/AM/LLY@Lilly
Subject: Forte and Powerbuilder Experience Needed
1) Do you have experience with PowerBuilder and Forte' applications running at
the same time on the same (laptop) computer? Here I'm thinking
about any potential resource constraints? Memory Requirements?
2) Can PowerBuilder and Forte' applications call and interact with one
another?
The Forte' application will need to interact with the PowerBuilder application
to pull out information maintained by the PB application.
Maybe you are looking for
-
I need a solution over it. i have check on your cummunity people saying to keep the phone in refrigerator that will solve the WIFI problem. i hope apple are considering on the quwries of the people such a major case need to be sort out soon where all
-
Hi there, my old mac book recently died and I opted to buy a new macbook pro, instead of pouring lots of money into the old computer. I was able to get my hard drive out, and I bought a 2.5" Sata Nootbook Drive Upgrade Kit. I have also installed su
-
I upgraded to itunes 11 on my pc and have not been able to edit/update my iphone 5 playlists. They appear grey-ed out in itunes. I got the dreaded message telling me the iphone was synced to another itunes library--though it never has been. I went th
-
Not sure if I am in the right forum, Has anyone used the hauppage for mac-suppose to let you watch and record TV shows on your mac and burn to dvd? If so, would appreciate their opinion ...... thanks.
-
Re: Is it possible to completely recover VistaOS using only Recovery DVD?
Hidden WinRE partition was deleted by mistake but I still got the original Recovery DVD for my A200. Is it possible to completely recover VistaOS without the WinRE partition, using only Recovery DVD?