Home » Developer & Programmer » Forms » memory usage ???
memory usage ??? [message #340941] Fri, 15 August 2008 01:59 Go to next message
raywong9i
Messages: 40
Registered: April 2008
Member
Hi all,

I have a form which are now converted to 10g version which will reference a table type defined in stored package, like this :

In forms trigger :
DECLARE
i_TDTL_RECORDS PKG_1.TBL_TYPE_1;
BEGIN
:
:
END;

where PKG_1 is a database package
and TBL_TYPE_1 is defined like the following :
TYPE TBL_TYPE_1 IS TABLE OF REC_1 INDEX BY BINARY_INTEGER;

I just wondering if I insert many records to i_TDTL_RECORDS,
is it use up the memory in Application Server or the Client PC ?

Thanks!
Re: memory usage ??? [message #340983 is a reply to message #340941] Fri, 15 August 2008 07:03 Go to previous messageGo to next message
Littlefoot
Messages: 21823
Registered: June 2005
Location: Croatia, Europe
Senior Member
Account Moderator
Quote:
is it use up the memory in Application Server or the Client PC ?

None of those, as far as I can tell. I'd put my bet on a Database Server.
Re: memory usage ??? [message #341277 is a reply to message #340941] Mon, 18 August 2008 02:33 Go to previous messageGo to next message
raywong9i
Messages: 40
Registered: April 2008
Member
Oh, that's what I don't know about this.

I just think the problem reference the type defined the DB side,
but the actual memory usuage is AS or Client side.

I am still confused in this ???????

Actually, my problem is sometime I load many records (40000 records) to the table, it will show up the FRM-92101:Therewas a failure in the Forms Server during startup.............
But this won't happen when I load few records. So I suspect is the memory problem.
Re: memory usage ??? [message #341448 is a reply to message #341277] Mon, 18 August 2008 21:07 Go to previous messageGo to next message
djmartin
Messages: 10181
Registered: March 2005
Location: Surges Bay TAS Australia
Senior Member
Account Moderator
I suspect your RBS or SGA is too small. Try committing your changes every thousand rows or so.

David
Re: memory usage ??? [message #341669 is a reply to message #340941] Tue, 19 August 2008 21:33 Go to previous messageGo to next message
raywong9i
Messages: 40
Registered: April 2008
Member
Thanks, but we didn't do any insert/update/delete in this procedure, so ....seems this is not the commit problem.

Actually, we just load the data to the array and then do some processing, after that we write to a file in the client side.

However, when we load for huge records, then the error shown and then closed in between of the process.

Btw, I still not sure which memory is the array using Client/ AS/ or DB server ?



Re: memory usage ??? [message #341715 is a reply to message #341669] Wed, 20 August 2008 01:43 Go to previous messageGo to next message
djmartin
Messages: 10181
Registered: March 2005
Location: Surges Bay TAS Australia
Senior Member
Account Moderator
If you don't "insert/update/delete" what do you do with the 40,000 records that you are processing?

David
Re: memory usage ??? [message #341964 is a reply to message #340941] Wed, 20 August 2008 22:43 Go to previous messageGo to next message
raywong9i
Messages: 40
Registered: April 2008
Member
the cureent logic just load the records to the array, and then do some checking and then write to a file.

May be I should move the checking to the server-side.
Re: memory usage ??? [message #342011 is a reply to message #341964] Thu, 21 August 2008 01:17 Go to previous message
djmartin
Messages: 10181
Registered: March 2005
Location: Surges Bay TAS Australia
Senior Member
Account Moderator
This sounds more like a Java or browser storage problem.

How much disk space is available on your PC?

Try defining a 'TMP' and a 'TEMP' environment variable on your PC and point it to a directory to which you have write access and which has enough room to hold the incoming file 2 or 3 times over.

David
Previous Topic: Oracle Forms First time Use
Next Topic: How should I know if a block is related to another block
Goto Forum:
  


Current Time: Mon Feb 03 09:52:00 CST 2025