RE: (forte-users) Hash tables vs 'sparse' arrays

The main difference is that the Array class does not have any method for
locating the object you are looking for, while the hash table has it (using
a object of type HashFunc).
If you are going to retrieve sequentially every element from the array then
it may be better choice, but if you do not know which element you will need
to retrieve then the hash table is much better choice.
Hope this helps
Dimitar
-----Original Message-----
From: Duncan Kinnear
To: kamranaminyahoo.com
Sent: 4/16/00 5:17 PM
Subject: (forte-users) Hash tables vs 'sparse' arrays
Can someone tell me what the differences would be between a hash
table and an array with 'randomly' filled entries (e.g. with entries at
positions 1, 37, 342 and 1003).
Would the array take up 'space' for the entries that are empty? Would
the array be faster?
Any comments greatly appreciated.
Cheers,
Duncan Kinnear,
McCarthy and Associates, Email:
duncanMcCarthy.co.nz
PO Box 764, McLean Towers, Phone: +64 6 834 3360
Shakespeare Road, Napier, New Zealand. Fax: +64 6 834 3369
Providing Integrated Software to the Meat Processing Industry for over
10 years
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

Similar Messages

How do I use Get-ADUser to get just the Managers attribute? And then get rid of duplicates in my array/hash table?

Hello,
I am trying to just get the Managers of my users in Active Directory. I have gotten it down to the user and their manager, but I don't need the user. Here is my code so far:
Get-ADUser-filter*-searchbase"OU=REDACTED,
OU=Enterprise Users, DC=REDACTED, DC=REDACTED"-PropertiesManager|SelectName,@{N='Manager';E={(Get-ADUser$_.Manager).Name}}
|export-csvc:\managers.csv-append
Also, I need to get rid of the duplicate values in my hash table. I tried playing around with -sort unique, but couldn't find a place it would work. Any help would be awesome.
Thanks,
Matt

I would caution that, although it is not likely, managers can also be contact, group, or computer objects. If this is possible in your situation, use Get-ADObject in place of Get-ADUser inside the curly braces.
Also, if you only want users that have a manager assigned, you can use -LDAPFilter "(manager=*)" in the first Get-ADUser.
Finally, if you want all users that have been assigned the manager for at least one user, you can use:
Get-ADUser
-LDAPFilter "(directReports=*)" |
Select @{N='Manager';E={ (Get-ADUser
$_.sAMAccountName).Name }}
-Unique | Sort Manager |
Export-Csv .\managerList.csv -NoTypeInformation
This works because when you assign the manager attribute of a user, this assigns the user to the directReports attribute of the manager. The directReports atttribute is multi-valued (an array in essence).
Again, if managers can be groups or some other class of object (not likely), then use Get-ADObect throughout and identify by distinguishedName instead of sAMAccountName (since contacts don't have sAMAccountName).
Richard Mueller - MVP Directory Services

RE: (forte-users) SQL Array Insert

Unfortunately that carries a tremendous overhead. Each request is a seperate
message and forte generates alot of behind the scenes prepares for the sql.
---------------------- Forwarded by Amos G. Radford on 10/27/2000 02:34 PM
"Amin, Kamran" <kamran.aminlendware.com> on 10/27/2000 02:33:07 PM
To: Amos G. RadfordBankofAmerica
cc:
Class: Internal Use Only
Subject: RE: (forte-users) SQL Array Insert
User a for loop and call update for each row in the array.
For Loop
Update
set
1=test[1]
end for
ka
-----Original Message-----
From: Amos.G.Radfordbankofamerica.com
[mailto:Amos.G.Radfordbankofamerica.com]
Sent: Friday, October 27, 2000 12:07 PM
To: forte-userslists.xpedior.com
Subject: (forte-users) SQL Array Insert
I have run into a strange problem that I never really run into
before. If I want to save an array of items into a table in TOOL
SQL, how can I do it if the column names in the table are different
than the column names in the class. In the past we always had
the luxury of the column names being the same.
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

Madhu,
Do the following:
1. create prepare statement
e.g
stmHnd : DBStatementHandle;
inputData : DBDataset = new;
stmType : integer;
stmHnd = DBSesObj.prepare('insert into
table_name myCOl1, myCol2, myCol3
values(:myCol1Value, :myCol2Value, :myCol3Value)',
inputData,stmType);
2. Populate the input DBDataset.
e.g
// assign the maximum value
inputData = myArrObj.items;
// assign the values
for i in 1 to myArrObj.items do
inputdata.currentRow = i;
inputdata.setvalue(':myCol1Value',
myArrObj.attr1);
inputdata.setvalue(':myCol2Value',
myArrObj[i].attr2);
inputdata.setvalue(':myCol3Value',
myArrObj[i].attr3);
end for;
3. execute the statement:
e.g .
DBSesObj.execute(stmHnd, inputData);
4. release the handle
DBSesObj.RemoveStatement(stmHnd);
Hope this helps,
Babu
--- "Epari, Madhusudhan" <meparioxhp.com> wrote:
Babu,
I'm not clear on how dynamic sql statement would
access the database only
one time for inserting an array of records in to the
table. Could you tell
how's it done?
thanks in advance,
Madhu
-----Original Message-----
From: Babu Raj [mailto:ibcsmartboyyahoo.com]
Sent: Friday, October 27, 2000 8:02 PM
To: Amos.G.Radfordbankofamerica.com;
forte-userslists.xpedior.com
Subject: RE: (forte-users) SQL Array Insert
Amos,
Why don't you use, Dyanmic SQL statement,
where
you need to prepare only one SQL Statement, and
populate input place holder, which is much simpler
and
you need to access the database only one time(which
is
efficient operation). This is useful, especially,
when
you want to update. But for your inforamtion, Forte
internally inserts, one by one row, even if u call
Static SQl statement, with array of record. Os its
advisable to use Dyanmic SQL statement.
Hope this helps,
Babu
--- Amos.G.Radfordbankofamerica.com wrote:
Unfortunately that carries a tremendous overhead.
Each request is a seperate
message and forte generates alot of behind the
scenes prepares for the sql.
---------------------- Forwarded by Amos G.Radford
on 10/27/2000 02:34 PM
"Amin, Kamran" <kamran.aminlendware.com> on
10/27/2000 02:33:07 PM
To: Amos G. RadfordBankofAmerica
cc:
Class: Internal Use Only
Subject: RE: (forte-users) SQL Array Insert
User a for loop and call update for each row inthe
array.
For Loop
Update
set
1=test[1]
end for
ka
-----Original Message-----
From: Amos.G.Radfordbankofamerica.com
[mailto:Amos.G.Radfordbankofamerica.com]
Sent: Friday, October 27, 2000 12:07 PM
To: forte-userslists.xpedior.com
Subject: (forte-users) SQL Array Insert
I have run into a strange problem that I never
really run into
before. If I want to save an array of items intoa
table in TOOL
SQL, how can I do it if the column names in the
table are different
than the column names in the class. In the pastwe
always had
the luxury of the column names being the same.
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
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
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

Question about comparing an array of names to a hash table

I'm still learning Powershell but feel like I have the basics now. I have a new project I'm working on and want some input as the best way to do this:
The Problem:
Let's say you have a list of several hundred video game titles and the dollar value of each in a text or two column CSV file.
The example CSV file looks likes this:
Game, Price
Metroid, $15.00
The Legend of Zelda!, $12.00
Mike Tyson's Punch-Out!, $18.00
Super Mario Bros., $16.00
Kung Fu, $7.00
You have another list of just the video game titles, this most likely is just a text file with each title listed on its own line.
The example text file looks like this:
Kung Fu
Metroid
Mike Tysons Punch-Out
Legend of Zelda
What I think would happen in the Script:
Use import-csv and create a hash table that will contain a key = Title and the value = the price.
Use import-csv and create an array for the title names.
Foreach loop through each Game Title and match the value against the Hash Table, if there's a match found, put that into another array that will later add all prices of each item and give you a total sum.
The challenge:
So far when I try and do one line examples of comparing names against the hash table it seems to only work with exact name matches. In the above example I've purposely made the game titles slightly different because in the real world people just write things
differently.
With that said, I've tried using the following single line to match things up and it only seems to work if the values match exactly.
$hash_table.ContainsKey("Game Title")
Is there a regex I should use to change the input of the game titles before creating the hash table or doing the compare? Is there another matching operator that is better and matching with String values that have slightly different grammar. An example would
be the game "The Legend of Zelda". Sometimes people just put "Legend of Zelda", that's close but not exact. I think using a regex to remove extra spaces and symbols would work, but what about for matching of words or letters??
Any ideas would be very helpful and thanks!

There's no pat answer for this.
You can create an array from the hash table keys:
$hashtable = @{"The Legend of Zelda" = 15.00}
$titles = $hashtable.getenumerator() | select -ExpandProperty Name
And then test that using a wildcard match:
$titles -like "*Game Title*"
and see if it returns just one match. If it does then use that match to do your lookup in the hash table. If it returns 0, or more than one match then you need to check the spelling or qualify the title search some more.
[string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "

Re: Hash table usage

The Born collection classes don't have an alternative implementation of
HashTable. Instead they are wrappers around the Forté Framework classes
using Array, HashTable etc.
Raymond Blum wrote:
>
Eric
Although I have not looked at them in a while, I remember the Born
Collection Classes having some HashTable and Iterator functionality that
might be worth looking at as an alternative.
The last version I had is 1.2 and was offered under the GNU license,
there may be something newer, check out
http://www.born.com
or email
[email protected]
On Thu, 6 May 1999, Fingerhut, Eric wrote:
We have been using the hashtable class in our application, and have recently
hit performance problems that lead us to the following questions:
1) Forte's hashing algorithm - we are concerned that Forte's hashing
algorithm may not be ideal or even adequate for our data; does anyone know
how it works?
2) Hash table performance - any ideas on how to guage it?
3) Is anyone aware of a binary tree implementation that might be
available?
Dr. Thomas Kunst mailto:[email protected]
sd&m GmbH & Co. KG http://www.sdm.de
software design & management
Thomas-Dehler-Str. 27, 81737 Muenchen, Germany
Tel +49 89 63812-221 Fax -444
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

I'm trying to understand what you have and what you are trying to do. First of all, the Web PL/SQL generator requires you to generate Table APIs (TAPIs) for every table referenced in a module component. If you created one based on a view, the only way to get it to work is to generate a TAPI on the view, which Designer doesn't do natively. I've fooled Designer into generating a view TAPI by creating a table definition that looks exactly like the view and has the same name, and generating the TAPI for that table. Even then, I have to hand-modify the resulting TAPI to remove references to ROWID, since views don't have rowids.
I've never tried generating TAPI against a materialized view (MV) - it might work, since there really is a table to instantiate the MV, but it might require the same work around as the view.
As for the reference in the module component definition, I think you have to delete the old table reference and create a new one. I'm not sure what you are doing with "copy object". Remapping is usually done when you are copying an object from one application system to another, and want the references to point at equivalent objects in the new application system, not the objects in the old one.

Re: (forte-users) TreeView image of a nodedisappears

Hashtables, just like arrays ( are expected to ) grow once you exceed the
initial (setup) size. The size that is specified at the creation time is
only the initial size. When you add more elements than what it can
accomodate, the effective size of the hashtable is increased by making one
(or more ) of the bucket pointers to point to sub-tables/arrays.
Eventhough the rearrangement is transparent to the programmer, you should
note that the performance of the look-up algorithm might reduce slightly
with each "growth".
Forte technote 10971 ( LargeArrays, and Hash Tables )nicely explains how
these data structures are managed.
Hope this helps,
Ajith Kallambella M.
From: "Braja Chattaraj" <forte_brajachotmail.com>
To: forte-userslists.xpedior.com
Subject: (forte-users) Max size of a hash table.
Date: Tue, 20 Mar 2001 12:05:45 -0500
We are trying a performance test and have discovered that the hash table
data structure has a max limit of 32767. The setup() method would not take
anything more than 32767 for the size parameter. The documentation does not
say anything about a max limit for a hash table. Evidently it is using a
signed integer of 2 bytes for the size.
We have been using the hash table to check for the uniqueness of a large
data set of 100,000 ids (rather than looping through the set for each id).
Any duplicates raise an exception which is trapped to validate the
duplicates. We could probably set the size of the hash table to 32767 if we
are sampling more than that many ids but I am not sure about the
performance
if we do so. Will try though
Any comments, suggestions or insight will be appreciated.
Thanks,
Braja.
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

Displaying graphical representation of data in hash tables as bar chart?

I want to be able to display results in my hash table as a bar chart i don't know how to do it could someone help me I've looked through tutorials couldn't find any information that actually helped.
In my program it doesnt allow matching the capital and small letters
so for instance if I already have Mike it allows for me to input mike in again so there are 2 Mikes.
I also want to do a simple user interface the tutorial for it is not simple to understand could any one tell me how to create a simple user interface like putting a button into a place wher i want it to be.
im not asking anyone to do it for me i just want people to show me how to do it
thank you
Edited by: Tek_Hedef on Dec 1, 2007 4:30 AM

Thanks for the ideas pal but I did have a go at it but my bit of code is making it crash but i removed it now so here's what I have so far
import java.io.*;
import java.util.*;
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import javax.swing.event.*;
class StudentDetails extends JFrame implements ActionListener
     private JTextField StudentNameTxt, StudentMarkTxt;
    private JButton DeleteStudentDetailsBtn, DisplayAllStudentsBtn, SearchStudentBtn, FailedStudentsBtn, PassedStudentsBtn, DistinctionStudentsBtn, AddStudentDetailsBtn, ExitBtn;
    private JPanel DisplayStudentDetailsPnl;
    private JLabel StudentNameLbl, StudentMarkLbl;
    private JTextArea DisplayResultsTxt;
    private Hashtable StudentDetailsTbl;
    private String StudentName, StudentMark;
    public static void main(String[] args)
        StudentDetails frame = new StudentDetails();
         frame.setSize(600,600);
        frame.createGUI();
        frame.setVisible(true);
    public void display(JPanel DisplayStudentDetailsPnl)
        Graphics paper = DisplayStudentDetailsPnl.getGraphics();
        paper.setColor(Color.white);
        paper.fillRect(0, 0, 500, 500);
        paper.setColor(new Color((int)(Math.random()*255),(int)(Math.random()*255),(int)(Math.random()*255) ));
    private void createGUI()
        setDefaultCloseOperation(EXIT_ON_CLOSE);
        Container window = getContentPane();
        window.setLayout(new FlowLayout());
        StudentDetailsTbl = new Hashtable();
        StudentNameLbl = new JLabel("Student Name");
        window.add(StudentNameLbl);
        StudentNameTxt = new JTextField(15);
        window.add(StudentNameTxt);
        StudentMarkLbl = new JLabel("Student Mark");
        window.add(StudentMarkLbl);
        StudentMarkTxt = new JTextField(3);
        window.add(StudentMarkTxt);
        AddStudentDetailsBtn = new JButton("Add Student and Mark");
        window.add(AddStudentDetailsBtn);
        AddStudentDetailsBtn.addActionListener(this);
        DeleteStudentDetailsBtn = new JButton("Delete Student");
        window.add(DeleteStudentDetailsBtn);
        DeleteStudentDetailsBtn.addActionListener(this);
        DisplayAllStudentsBtn = new JButton("Display all Students and Marks");
        window.add(DisplayAllStudentsBtn);
        DisplayAllStudentsBtn.addActionListener(this);
        SearchStudentBtn = new JButton("Search Student");
        window.add(SearchStudentBtn);
        SearchStudentBtn.addActionListener(this);
        FailedStudentsBtn = new JButton("Students which Failed");
        window.add(FailedStudentsBtn);
        FailedStudentsBtn.addActionListener(this);
        PassedStudentsBtn = new JButton("Students which Passed");
        window.add(PassedStudentsBtn);
        PassedStudentsBtn.addActionListener(this);
        DistinctionStudentsBtn = new JButton("Students with Distinction");
        window.add(DistinctionStudentsBtn);
        DistinctionStudentsBtn.addActionListener(this);
        ExitBtn = new JButton("Exit");
        window.add(ExitBtn);
        ExitBtn.addActionListener(this);
        DisplayResultsTxt = new JTextArea();
        DisplayResultsTxt.setPreferredSize(new Dimension(200, 200));
        DisplayResultsTxt.setBackground(Color.white);
        window.add(DisplayResultsTxt);
        DisplayResultsTxt.enable(false);
    public void actionPerformed (ActionEvent e)
         if (e.getSource()== AddStudentDetailsBtn)
              StudentName = StudentNameTxt.getText();
               StudentMark = StudentMarkTxt.getText();
              DisplayResultsTxt.setText("");
              StudentDetailsTbl.put(StudentName, StudentMark);
            Enumeration enumStudentName = StudentDetailsTbl.keys();
            Enumeration enumStudentMark = StudentDetailsTbl.elements();
            String[] keys = (String[]) StudentDetailsTbl.keySet().toArray(new String[0]);
            Arrays.sort(keys);
                for (String key : keys)
                     DisplayResultsTxt.append(key + " : " + StudentDetailsTbl.get(key)+ "\n");
                StudentNameTxt.setText("");
                StudentMarkTxt.setText("");
         if (e.getSource() == DeleteStudentDetailsBtn )
         if (StudentDetailsTbl.containsKey(StudentNameTxt.getText().trim()))
              DisplayResultsTxt.setText("");
              String txt = StudentNameTxt.getText();
            Enumeration enumStudentName = StudentDetailsTbl.keys() ;
                String currentelement = (String)enumStudentName.nextElement();
                 StudentDetailsTbl.remove(txt);
                 DisplayResultsTxt.append(txt + " has been deleted");
        if (e.getSource() == SearchStudentBtn)
        if (StudentDetailsTbl.containsKey(StudentNameTxt.getText().trim()))
             String txt = StudentNameTxt.getText();
             String result;
             DisplayResultsTxt.setText("");
             Enumeration enumStudentName = StudentDetailsTbl.keys();
            Enumeration enumStudentMark = StudentDetailsTbl.elements();
               while (enumStudentName.hasMoreElements())
                    String currentelement = (String)enumStudentName.nextElement();
                result = (StudentDetailsTbl.get(currentelement).toString());
                    if (txt.equals(currentelement))
                         DisplayResultsTxt.append(currentelement + " " + result);
                    else JOptionPane.showMessageDialog(null, "Student Name could not be identified");
        if (e.getSource() == DisplayAllStudentsBtn)
              DisplayResultsTxt.setText("");
             Enumeration enumStudentName = StudentDetailsTbl.keys();
            Enumeration enumStudentMark = StudentDetailsTbl.elements();
            while (enumStudentName.hasMoreElements())
            DisplayResultsTxt.append(enumStudentName.nextElement()+ " " + enumStudentMark.nextElement()+ "\n");
        if (e.getSource() == PassedStudentsBtn)
             DisplayResultsTxt.setText("");
             Enumeration enumStudentName = StudentDetailsTbl.keys();
            Enumeration enumStudentMark = StudentDetailsTbl.elements();
            while (enumStudentName.hasMoreElements())
                 int Mark = Integer.parseInt((String)enumStudentMark.nextElement());
                 String Name = (String)enumStudentName.nextElement();
                 if (Mark >=40)
                      DisplayResultsTxt.append(Name + " " + Mark + "\n");
        if (e.getSource() == FailedStudentsBtn)
             DisplayResultsTxt.setText("");
             Enumeration enumStudentName = StudentDetailsTbl.keys();
            Enumeration enumStudentMark = StudentDetailsTbl.elements();
            while (enumStudentName.hasMoreElements())
                 int Mark = Integer.parseInt((String)enumStudentMark.nextElement());
                 String Name = (String)enumStudentName.nextElement();
                 if (Mark <40)
                      DisplayResultsTxt.append(Name + " " + Mark + "\n");
        if (e.getSource() == DistinctionStudentsBtn)
             DisplayResultsTxt.setText("");
             Enumeration enumStudentName = StudentDetailsTbl.keys();
            Enumeration enumStudentMark = StudentDetailsTbl.elements();
            while (enumStudentName.hasMoreElements())
                 int Mark = Integer.parseInt((String)enumStudentMark.nextElement());
                 String Name = (String)enumStudentName.nextElement();
                 if (Mark >=75)
                      DisplayResultsTxt.append(Name + " " + Mark + "\n");
}

RE: (forte-users) Hi All....very urgent...Forte doesn'thandle La rge ar

Okay, here's my three cents worth,
Are you using Forte "Keep Alive" settings? If yes, you may simply have a
time-out.
While a partition is waiting for a reply from a database, it blocks and
won't respond
to anything, including pings to check if it's still alive. So, if the query
takes longer to
complete than the time-out period of the communication manager, then you
will
loose the connection to the partition.
-----Original Message-----
From: Aberdour George [SMTP:george.aberdourdet.nsw.edu.au]
Sent: Sunday, February 13, 2000 11:39 AM
To: 'Babu Raj'; kamranaminyahoo.com
Subject: RE: (forte-users) Hi All....very urgent...Forte doesn't
handle La rge array properly
Hi,
This sounds almost identical to a problem we have experienced.
If it is the same problem it is because you have compiled a back-end
load-balanced partition, but NOT the router that manages it.
With such a configuration, attempts to send greater than a few thousand
rows
will fail - and it doesn't seem to matter what you set -fm to.
You don't see the problem running distributed from your workspace because
everything is interpreted.
So just compile the router and try again.
Hope this helps.
George Aberdour
(George.Aberdourdet.nsw.edu.au)
-----Original Message-----
From: Babu Raj [mailto:ibcsmartboyyahoo.com]
Sent: Saturday, 12 February 2000 7:24
To: kamranaminyahoo.com
Subject: (forte-users) Hi All....very urgent...Forte doesn't handle
Large array properly
Hi All,
Have anyone experienced problem of retrieving
more than 1500 records from the database table, into
the object.
I use dynamic SQL statement, and populating Array
object from the DBDataSet. When it runs from my
workspace distributed, it works fine. But, when I make
deployment, and install on the test bed, I face
Network connection failure from the client machine. It
looks like, server read the data from the Database,
and while packaging it, to send it across to the
client, server seems to run out ouf memory or couldn't
maintain the connection with the client. I tried to
set -fm flag on that partition, and separately setting
FORTE_GC_SPECIAL too, but still no luck.
we have increased, the rollback segment size on
Oracle too, but still no luck.
Appreciate, your suggestions, if you can,
Thank you,
Babu
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
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

Okay, here's my three cents worth,
Are you using Forte "Keep Alive" settings? If yes, you may simply have a
time-out.
While a partition is waiting for a reply from a database, it blocks and
won't respond
to anything, including pings to check if it's still alive. So, if the query
takes longer to
complete than the time-out period of the communication manager, then you
will
loose the connection to the partition.
-----Original Message-----
From: Aberdour George [SMTP:george.aberdourdet.nsw.edu.au]
Sent: Sunday, February 13, 2000 11:39 AM
To: 'Babu Raj'; kamranaminyahoo.com
Subject: RE: (forte-users) Hi All....very urgent...Forte doesn't
handle La rge array properly
Hi,
This sounds almost identical to a problem we have experienced.
If it is the same problem it is because you have compiled a back-end
load-balanced partition, but NOT the router that manages it.
With such a configuration, attempts to send greater than a few thousand
rows
will fail - and it doesn't seem to matter what you set -fm to.
You don't see the problem running distributed from your workspace because
everything is interpreted.
So just compile the router and try again.
Hope this helps.
George Aberdour
(George.Aberdourdet.nsw.edu.au)
-----Original Message-----
From: Babu Raj [mailto:ibcsmartboyyahoo.com]
Sent: Saturday, 12 February 2000 7:24
To: kamranaminyahoo.com
Subject: (forte-users) Hi All....very urgent...Forte doesn't handle
Large array properly
Hi All,
Have anyone experienced problem of retrieving
more than 1500 records from the database table, into
the object.
I use dynamic SQL statement, and populating Array
object from the DBDataSet. When it runs from my
workspace distributed, it works fine. But, when I make
deployment, and install on the test bed, I face
Network connection failure from the client machine. It
looks like, server read the data from the Database,
and while packaging it, to send it across to the
client, server seems to run out ouf memory or couldn't
maintain the connection with the client. I tried to
set -fm flag on that partition, and separately setting
FORTE_GC_SPECIAL too, but still no luck.
we have increased, the rollback segment size on
Oracle too, but still no luck.
Appreciate, your suggestions, if you can,
Thank you,
Babu
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
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

How to fill a hashed table ?

Hi,
In my last thread i had asked about the ways of deleting the cube contents selectively using a job/FM and i was suggested this by one of you.
CALL FUNCTION 'RSDRD_SEL_DELETION'
EXPORTING
I_DATATARGET = 'YOUR_CUBE'
I_THX_SEL = L_THX_SEL
I_AUTHORITY_CHECK = 'X'
I_THRESHOLD = '1.0000E-01'
I_MODE = 'C'
I_NO_LOGGING = ''
I_PARALLEL_DEGREE = 1
I_NO_COMMIT = ''
CHANGING
C_T_MSG = L_T_MSG.
Although the FM is the correct one the structure L_THX_SEL is a hashed table structure and i am not aware how to fill values into it. My requirement is to give a condition for the 0CALDAY info-object i.e 0CALDAY < 30 days. Please suggest me.
Regadrs,
Pramod M

HI,
Internal Tables
Internal tables provide a means of taking data from a fixed structure and storing it in working memory in ABAP. The data is stored line by line in memory, and each line has the same structure. In ABAP, internal tables fulfill the function of arrays. Since they are dynamic data objects, they save the programmer the task of dynamic memory management in his or her programs. You should use internal tables whenever you want to process a dataset with a fixed structure within a program. A particularly important use for internal tables is for storing and formatting data from a database table within a program. They are also a good way of including very complicated data structures in an ABAP program.
Data Type of an Internal Table
The data type of an internal table is fully specified by its line type, key, and table type.
Line Type
The line type of an internal table can be any data type. The data type of an internal table is normally a structure. Each component of the structure is a column in the internal table. However, the line type may also be elementary or another internal table.
Key
The key identifies table rows. There are two kinds of key for internal tables - the standard key and a user-defined key. You can specify whether the key should be UNIQUE or NON-UNIQUE. Internal tables with a unique key cannot contain duplicate entries. The uniqueness depends on the table access method.
At tables with structured row type, the standard key is formed from all character-type columns of the internal table. If a table has an elementary line type, the default key is the entire line. The default key of an internal table whose line type is an internal table, the default key is empty. At tables with non-structured row type, the standard key consists of the entire row. If the row type is also a table, an empty key is defined.
The user-defined key can contain any columns of the internal table that are no internal table themselves, and do not contain internal tables. References are allowed as table keys. Internal tables with a user-defined key are called key tables. When you define the key, the sequence of the key fields is significant. You should remember this, for example, if you intend to sort the table according to the key.
Table type
The table type determines how ABAP will access individual table entries. Internal tables can be divided into three types:
Standard tables have an internal linear index. From a particular size upwards, the indexes of internal tables are administered as trees. In this case, the index administration overhead increases in logarithmic and not linear relation to the number of lines. The system can access records either by using the table index or the key. The response time for key access is proportional to the number of entries in the table. The key of a standard table is always non-unique. You cannot specify a unique key. This means that standard tables can always be filled very quickly, since the system does not have to check whether there are already existing entries.
Sorted tables are always saved sorted by the key. They also have an internal index. The system can access records either by using the table index or the key. The response time for key access is logarithmically proportional to the number of table entries, since the system uses a binary search. The key of a sorted table can be either unique or non-unique. When you define the table, you must specify whether the key is to be UNIQUE or NON-UNIQUE. Standard tables and sorted tables are known generically as index tables.
Hashed tables have no linear index. You can only access a hashed table using its key. The response time is independent of the number of table entries, and is constant, since the system access the table entries using a hash algorithm. The key of a hashed table must be unique. When you define the table, you must specify the key as UNIQUE.
Generic Internal Tables
Unlike other local data types in programs, you do not have to specify the data type of an internal table fully. Instead, you can specify a generic construction, that is, the key or key and line type of an internal table data type may remain unspecified. You can use generic internal tables to specify the types of field symbols and the interface parameters of procedures . You cannot use them to declare data objects.
Internal Tables as Dynamic Data Objects
Internal tables are always completely specified regarding row type, key and access type. However, the number of lines is not fixed. Thus internal tables are dynamic data objects, since they can contain any number of lines of a particular type. The only restriction on the number of lines an internal table may contain are the limits of your system installation. The maximum memory that can be occupied by an internal table (including its internal administration) is 2 gigabytes. A more realistic figure is up to 500 megabytes. An additional restriction for hashed tables is that they may not contain more than 2 million entries. The line types of internal tables can be any ABAP data types - elementary, structured, or internal tables. The individual lines of an internal table are called table lines or table entries. Each component of a structured line is called a column in the internal table.
Choosing a Table Type
The table type (and particularly the access method) that you will use depends on how the typical internal table operations will be most frequently executed.
Standard tables
This is the most appropriate type if you are going to address the individual table entries using the index. Index access is the quickest possible access. You should fill a standard table by appending lines (ABAP APPENDstatement), and read, modify and delete entries by specifying the index (INDEX option with the relevant ABAP command). The access time for a standard table increases in a linear relationship with the number of table entries. If you need key access, standard tables are particularly useful if you can fill and process the table in separate steps. For example, you could fill the table by appending entries, and then sort it. If you use the binary search option (BINARY) with key access, the response time is logarithmically proportional to the number of table entries.
Sorted tables
This is the most appropriate type if you need a table which is sorted as you fill it. You fill sorted tables using the INSERTstatement. Entries are inserted according to the sort sequence defined through the table key. Any illegal entries are recognized as soon as you try to add them to the table. The response time for key access is logarithmically proportional to the number of table entries, since the system always uses a binary search. Sorted tables are particularly useful for partially sequential processing in a LOOP if you specify the beginning of the table key in the WHEREcondition.
Hashed tables
This is the most appropriate type for any table where the main operation is key access. You cannot access a hashed table using its index. The response time for key access remains constant, regardless of the number of table entries. Like database tables, hashed tables always have a unique key. Hashed tables are useful if you want to construct and use an internal table which resembles a database table or for processing large amounts of data.
If help full please give me max Reward

Producing a string of 3 random letters for a hash table

I'm pretty new to all this and i was wondering if anyone would be able to help me produce a random string of 3 letters to be inputted into a hash table. I already have the code for integers to be placed into the table but am having difficulty with letters. I've tried using the Random() function but am probably putting it into the wrong place.
I will place the code underneath so you can all have a look at it.
Any help would be greatly appreciated.
Thanks in advance
Code:
class HashTable
private DataItem[] hashArray; // array holds hash table
private int arraySize;
private DataItem nonItem; // for deleted items
public HashTable(int size) // constructor
arraySize = size;
hashArray = new DataItem[arraySize];
nonItem = new DataItem(-1); // deleted item key is -1
public void displayTable()
System.out.print("Table: ");
for(int j=0; j<arraySize; j++)
if(hashArray[j] != null)
System.out.print(hashArray[j].getKey() + " ");
else
System.out.print("** ");
System.out.println("");
public int hashFunc(int key)
return key % arraySize; // hash function
public void insert(DataItem item) // insert a DataItem
// (assumes table not full)
int key = item.getKey(); // extract key
int hashVal = hashFunc(key); // hash the key
// until empty cell or -1,
while(hashArray[hashVal] != null &&
hashArray[hashVal].getKey() != -1)
++hashVal; // go to next cell
hashVal %= arraySize; // wraparound if necessary
hashArray[hashVal] = item; // insert item
} // end insert()
public DataItem delete(int key) // delete a DataItem
int hashVal = hashFunc(key); // hash the key
while(hashArray[hashVal] != null) // until empty cell,
{                               // found the key?
if(hashArray[hashVal].getKey() == key)
DataItem temp = hashArray[hashVal]; // save item
hashArray[hashVal] = nonItem; // delete item
return temp; // return item
++hashVal; // go to next cell
hashVal %= arraySize; // wraparound if necessary
return null; // can't find item
} // end delete()
public DataItem find(int key) // find item with key
int hashVal = hashFunc(key); // hash the key
while(hashArray[hashVal] != null) // until empty cell,
{                               // found the key?
if(hashArray[hashVal].getKey() == key)
return hashArray[hashVal]; // yes, return item
++hashVal; // go to next cell
hashVal %= arraySize; // wraparound if necessary
return null; // can't find item
} // end class HashTable
class HashTableApp
public static void main(String[] args) throws IOException
DataItem aDataItem;
int aKey, size, n, keysPerCell;
// get sizes
System.out.print("Enter size of hash table: ");
size = getInt();
System.out.print("Enter initial number of items: ");
n = getInt();
keysPerCell = 10;
// make table
HashTable theHashTable = new HashTable(size);
for(int j=0; j<n; j++) // insert data
aKey = (int)(java.lang.Math.random() *
keysPerCell * size);
aDataItem = new DataItem(aKey);
theHashTable.insert(aDataItem);
while(true) // interact with user
System.out.print("Enter first letter of ");
System.out.print("show, insert, delete, or find: ");
char choice = getChar();
switch(choice)
case 's':
theHashTable.displayTable();
break;
case 'i':
System.out.print("Enter key value to insert: ");
aKey = getInt();
aDataItem = new DataItem(aKey);
theHashTable.insert(aDataItem);
break;
case 'd':
System.out.print("Enter key value to delete: ");
aKey = getInt();
theHashTable.delete(aKey);
break;
case 'f':
System.out.print("Enter key value to find: ");
aKey = getInt();
aDataItem = theHashTable.find(aKey);
if(aDataItem != null)
System.out.println("Found " + aKey);
else
System.out.println("Could not find " + aKey);
break;
default:
System.out.print("Invalid entry\n");
} // end switch
} // end while
} // end main()
public static String getString() throws IOException
InputStreamReader isr = new InputStreamReader(System.in);
BufferedReader br = new BufferedReader(isr);
String s = br.readLine();
return s;
public static char getChar() throws IOException
String s = getString();
return s.charAt(0);
public static int getInt() throws IOException
String s = getString();
return Integer.parseInt(s);
} // end class HashTableApp

public class Foo {
    private java.util.Random rand = new Random();
    public static void main(String[] args) throws Exception {
        new Foo().go();
    void go() throws Exception {
        String allowedChars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";
        System.out.println(getRandomString(allowedChars, 3));
    String getRandomString(String allowedChars, int length) {
        StringBuffer buf = new StringBuffer();
        int charCount = allowedChars.length();
        for (int count = 0; count < length; count++) {
            int index = rand.nextInt(charCount);
            buf.append(allowedChars.charAt(index));
        return buf.toString();
}

Hash table usage

We have been using the hashtable class in our application, and have recently
hit performance problems that lead us to the following questions:
1) Forte's hashing algorithm - we are concerned that Forte's hashing
algorithm may not be ideal or even adequate for our data; does anyone know
how it works?
2) Hash table performance - any ideas on how to guage it?
3) Is anyone aware of a binary tree implementation that might be
available?
Much thanks in advance,
Eric
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

We have been using the hashtable class in our application, and have recently
hit performance problems that lead us to the following questions:
1) Forte's hashing algorithm - we are concerned that Forte's hashing
algorithm may not be ideal or even adequate for our data; does anyone know
how it works?
2) Hash table performance - any ideas on how to guage it?
3) Is anyone aware of a binary tree implementation that might be
available?
Much thanks in advance,
Eric
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

SORTED & HASHED tables

Hi all
what exactly are the SORTED & HASHED tables??
Regards
Srini

Internal tables are the core of ABAP. They are like soul of a body. For any program we use
internal tables extensively. We can use Internal tables like normal data base tables only, but the
basic difference is the memory allocated for internal tables is temporary. Once the program is
closed the memory allocated for internal tables will also be out of memory.
But while using the internal tables, there are many performance issues to be considered. i.e which
type of internal table to be used for the program..like standard internal table, hashed internal
table or sorted internal table etc..
Internal tables
Internal tables provide a means of taking data from a fixed structure and storing it in working memory in ABAP. The data is stored line by
line in memory, and each line has the same structure. In ABAP, internal tables fulfill the function of arrays. Since they are dynamic data
objects, they save the programmer the task of dynamic memory management in his or her programs. You should use internal tables
whenever you want to process a dataset with a fixed structure within a program. A particularly important use for internal tables is for
storing and formatting data from a database table within a program. They are also a good way of including very complicated data
structures in an ABAP program.
Like all elements in the ABAP type concept, internal tables can exist both as data types and as data objects A data type is the abstract
description of an internal table, either in a program or centrally in the ABAP Dictionary, that you use to create a concrete data object. The
data type is also an attribute of an existing data object.
Internal Tables as Data Types
Internal tables and structures are the two structured data types in ABAP. The data type of an internal table is fully specified by its line type,
key, and table type.
Line type
The line type of an internal table can be any data type. The data type of an internal table is normally a structure. Each component of the
structure is a column in the internal table. However, the line type may also be elementary or another internal table.
Key
The key identifies table rows. There are two kinds of key for internal tables - the standard key and a user-defined key. You can specify
whether the key should be UNIQUE or NON-UNIQUE. Internal tables with a unique key cannot contain duplicate entries. The uniqueness
depends on the table access method.
If a table has a structured line type, its default key consists of all of its non-numerical columns that are not references or themselves
internal tables. If a table has an elementary line type, the default key is the entire line. The default key of an internal table whose line type
is an internal table, the default key is empty.
The user-defined key can contain any columns of the internal table that are not references or themselves internal tables. Internal tables
with a user-defined key are called key tables. When you define the key, the sequence of the key fields is significant. You should remember
this, for example, if you intend to sort the table according to the key.
Table type
The table type determines how ABAP will access individual table entries. Internal tables can be divided into three types:
Standard tables have an internal linear index. From a particular size upwards, the indexes of internal tables are administered as trees. In
this case, the index administration overhead increases in logarithmic and not linear relation to the number of lines. The system can access
records either by using the table index or the key. The response time for key access is proportional to the number of entries in the table.
The key of a standard table is always non-unique. You cannot specify a unique key. This means that standard tables can always be filled
very quickly, since the system does not have to check whether there are already existing entries.
Sorted tables are always saved sorted by the key. They also have an internal index. The system can access records either by using the
table index or the key. The response time for key access is logarithmically proportional to the number of table entries, since the system
uses a binary search. The key of a sorted table can be either unique or non-unique. When you define the table, you must specify whether
the key is to be unique or not. Standard tables and sorted tables are known generically as index tables.
Hashed tables have no linear index. You can only access a hashed table using its key. The response time is independent of the number of
table entries, and is constant, since the system access the table entries using a hash algorithm. The key of a hashed table must be unique.
When you define the table, you must specify the key as UNIQUE.
Generic Internal Tables
Unlike other local data types in programs, you do not have to specify the data type of an internal table fully. Instead, you can specify a
generic construction, that is, the key or key and line type of an internal table data type may remain unspecified. You can use generic
internal tables to specify the types of field symbols and the interface parameters of procedures . You cannot use them to declare data
objects.
Internal Tables as Dynamic Data Objects
Data objects that are defined either with the data type of an internal table, or directly as an internal table, are always fully defined in
respect of their line type, key and access method. However, the number of lines is not fixed. Thus internal tables are dynamic data objects,
since they can contain any number of lines of a particular type. The only restriction on the number of lines an internal table may contain are
the limits of your system installation. The maximum memory that can be occupied by an internal table (including its internal administration)
is 2 gigabytes. A more realistic figure is up to 500 megabytes. An additional restriction for hashed tables is that they may not contain more
than 2 million entries. The line types of internal tables can be any ABAP data types - elementary, structured, or internal tables. The
individual lines of an internal table are called table lines or table entries. Each component of a structured line is called a column in the
internal table.
Choosing a Table Type
The table type (and particularly the access method) that you will use depends on how the typical internal table operations will be most
frequently executed.
Standard tables
This is the most appropriate type if you are going to address the individual table entries using the index. Index access is the quickest
possible access. You should fill a standard table by appending lines (ABAP APPEND statement), and read, modify and delete entries by
specifying the index (INDEX option with the relevant ABAP command). The access time for a standard table increases in a linear relationship
with the number of table entries. If you need key access, standard tables are particularly useful if you can fill and process the table in
separate steps. For example, you could fill the table by appending entries, and then sort it. If you use the binary search option with key
access, the response time is logarithmically proportional to the number of table entries.
Sorted tables
This is the most appropriate type if you need a table which is sorted as you fill it. You fill sorted tables using the INSERT statement. Entries
are inserted according to the sort sequence defined through the table key. Any illegal entries are recognized as soon as you try to add
them to the table. The response time for key access is logarithmically proportional to the number of table entries, since the system always
uses a binary search. Sorted tables are particularly useful for partially sequential processing in a LOOP if you specify the beginning of the
table key in the WHERE condition.
Hashed tables
This is the most appropriate type for any table where the main operation is key access. You cannot access a hashed table using its index.
The response time for key access remains constant, regardless of the number of table entries. Like database tables, hashed tables always
have a unique key. Hashed tables are useful if you want to construct and use an internal table which resembles a database table or for
processing large amounts of data.
Creating Internal Tables
Like other elements in the ABAP type concept, you can declare internal tables as abstract data
types in programs or in the ABAP Dictionary, and then use them to define data objects.
Alternatively, you can define them directly as data objects. When you create an internal table as a
data object, you should ensure that only the administration entry which belongs to an internal
table is declared statically. The minimum size of an internal table is 256 bytes. This is important if an
internal table occurs as a component of an aggregated data object, since even empty internal
tables within tables can lead to high memory usage. (In the next functional release, the size of the
table header for an initial table will be reduced to 8 bytes). Unlike all other ABAP data objects, you
do not have to specify the memory required for an internal table. Table rows are added to and
deleted from the table dynamically at runtime by the various statements for adding and deleting
records.
You can create internal tables in different types.
You can create standard internal table and then make it sort in side the program.
The same way you can change to hashed internal tables also.
There will be some performance issues with regard to standard internal tables/ hashed internal
tables/ sorted internal tables.
Internal table types
This section describes how to define internal tables locally in a program. You can also define internal tables globally as data types in the
ABAP Dictionary.
Like all local data types in programs , you define internal tables using the TYPES statement. If you do not refer to an existing table type
using the TYPE or LIKE addition, you can use the TYPES statement to construct a new local internal table in your program.
TYPES <t> TYPE|LIKE <tabkind> OF <linetype> [WITH <key>]
[INITIAL SIZE <n>].
After TYPE or LIKE, there is no reference to an existing data type. Instead, the type constructor occurs:
<tabkind> OF <linetype> [WITH <key>]
The type constructor defines the table type <tabkind>, the line type <linetype>, and the key <key> of the internal table <t>.
You can, if you wish, allocate an initial amount of memory to the internal table using the INITIAL SIZE addition.
Table type
You can specify the table type <tabkind> as follows:
Generic table types
INDEX TABLE
For creating a generic table type with index access.
ANY TABLE
For creating a fully-generic table type.
Data types defined using generic types can currently only be used for field symbols and for interface parameters in procedures . The generic
type INDEX TABLE includes standard tables and sorted tables. These are the two table types for which index access is allowed. You cannot
pass hashed tables to field symbols or interface parameters defined in this way. The generic type ANY TABLE can represent any table. You
can pass tables of all three types to field symbols and interface parameters defined in this way. However, these field symbols and
parameters will then only allow operations that are possible for all tables, that is, index operations are not allowed.
Fully-Specified Table Types
STANDARD TABLE or TABLE
For creating standard tables.
<b>SORTED TABLE</b>
For creating sorted tables.
<b>HASHED TABLE</b>
For creating hashed tables.
Fully-specified table types determine how the system will access the entries in the table in key operations. It uses a linear search for
standard tables, a binary search for sorted tables, and a search using a hash algorithm for hashed tables.
Line type
For the line type <linetype>, you can specify:
Any data type if you are using the TYPE addition. This can be a predefined ABAP type, a local type in the program, or a data type from the
ABAP Dictionary. If you specify any of the generic elementary types C, N, P, or X, any attributes that you fail to specify (field length, number
of decimal places) are automatically filled with the default values. You cannot specify any other generic types.
Any data object recognized within the program at that point if you are using the LIKE addition. The line type adopts the fully-specified data
type of the data object to which you refer. Except for within classes, you can still use the LIKE addition to refer to database tables and
structures in the ABAP Dictionary (for compatibility reasons).
All of the lines in the internal table have the fully-specified technical attributes of the specified data type.
Key
You can specify the key <key> of an internal table as follows:
[UNIQUE|NON-UNIQUE] KEY <col1> ... <col n>
In tables with a structured line type, all of the components <coli> belong to the key as long as they are not internal tables or references,
and do not contain internal tables or references. Key fields can be nested structures. The substructures are expanded component by
component when you access the table using the key. The system follows the sequence of the key fields.
[UNIQUE|NON-UNIQUE] KEY TABLE LINE
If a table has an elementary line type (C, D, F, I, N, P, T, X), you can define the entire line as the key. If you try this for a table whose line
type is itself a table, a syntax error occurs. If a table has a structured line type, it is possible to specify the entire line as the key. However,
you should remember that this is often not suitable.
[UNIQUE|NON-UNIQUE] DEFAULT KEY
This declares the fields of the default key as the key fields. If the table has a structured line type, the default key contains all non-numeric
columns of the internal table that are not and do not contain references or internal tables. If the table has an elementary line type, the
default key is the entire line. The default key of an internal table whose line type is an internal table, the default key is empty.
Specifying a key is optional. If you do not specify a key, the system defines a table type with an arbitrary key. You can only use this to
define the types of field symbols and the interface parameters of procedures . For exceptions, refer to Special Features of Standard Tables.
The optional additions UNIQUE or NON-UNIQUE determine whether the key is to be unique or non-unique, that is, whether the table can
accept duplicate entries. If you do not specify UNIQUE or NON-UNIQUE for the key, the table type is generic in this respect. As such, it can
only be used for specifying types. When you specify the table type simultaneously, you must note the following restrictions:
You cannot use the UNIQUE addition for standard tables. The system always generates the NON-UNIQUE addition automatically.
You must always specify the UNIQUE option when you create a hashed table.
Initial Memory Requirement
You can specify the initial amount of main memory assigned to an internal table object when you define the data type using the following
addition:
INITIAL SIZE <n>
This size does not belong to the data type of the internal table, and does not affect the type check. You can use the above addition to
reserve memory space for <n> table lines when you declare the table object.
When this initial area is full, the system makes twice as much extra space available up to a limit of 8KB. Further memory areas of 12KB each
are then allocated.
You can usually leave it to the system to work out the initial memory requirement. The first time you fill the table, little memory is used. The
space occupied, depending on the line width, is 16 <= <n> <= 100.
It only makes sense to specify a concrete value of <n> if you can specify a precise number of table entries when you create the table and
need to allocate exactly that amount of memory (exception: Appending table lines to ranked lists). This can be particularly important for
deep-structured internal tables where the inner table only has a few entries (less than 5, for example).
To avoid excessive requests for memory, large values of <n> are treated as follows: The largest possible value of <n> is 8KB divided by the
length of the line. If you specify a larger value of <n>, the system calculates a new value so that n times the line width is around 12KB.
Examples
TYPES: BEGIN OF LINE,
COLUMN1 TYPE I,
COLUMN2 TYPE I,
COLUMN3 TYPE I,
END OF LINE.
TYPES ITAB TYPE SORTED TABLE OF LINE WITH UNIQUE KEY COLUMN1.
The program defines a table type ITAB. It is a sorted table, with line type of the structure LINE and a unique key of the component
COLUMN1.
TYPES VECTOR TYPE HASHED TABLE OF I WITH UNIQUE KEY TABLE LINE.
TYPES: BEGIN OF LINE,
COLUMN1 TYPE I,
COLUMN2 TYPE I,
COLUMN3 TYPE I,
END OF LINE.
TYPES ITAB TYPE SORTED TABLE OF LINE WITH UNIQUE KEY COLUMN1.
TYPES: BEGIN OF DEEPLINE,
FIELD TYPE C,
TABLE1 TYPE VECTOR,
TABLE2 TYPE ITAB,
END OF DEEPLINE.
TYPES DEEPTABLE TYPE STANDARD TABLE OF DEEPLINE
WITH DEFAULT KEY.
The program defines a table type VECTOR with type hashed table, the elementary line type I and a unique key of the entire table line. The
second table type is the same as in the previous example. The structure DEEPLINE contains the internal table as a component. The table
type DEEPTABLE has the line type DEEPLINE. Therefore, the elements of this internal table are themselves internal tables. The key is the
default key - in this case the column FIELD. The key is non-unique, since the table is a standard table.
Internal table objects
Internal tables are dynamic variable data objects. Like all variables, you declare them using the DATA statement. You can also declare static
internal tables in procedures using the STATICS statement, and static internal tables in classes using the CLASS-DATA statement. This
description is restricted to the DATA statement. However, it applies equally to the STATICS and CLASS-DATA statements.
Reference to Declared Internal Table Types
Like all other data objects, you can declare internal table objects using the LIKE or TYPE addition of the DATA statement.
DATA <itab> TYPE <type>|LIKE <obj> [WITH HEADER LINE].
Here, the LIKE addition refers to an existing table object in the same program. The TYPE addition can refer to an internal type in the
program declared using the TYPES statement, or a table type in the ABAP Dictionary.
You must ensure that you only refer to tables that are fully typed. Referring to generic table types (ANY TABLE, INDEX TABLE) or not
specifying the key fully is not allowed (for exceptions, refer to Special Features of Standard Tables).
The optional addition WITH HEADER line declares an extra data object with the same name and line type as the internal table. This data
object is known as the header line of the internal table. You use it as a work area when working with the internal table (see Using the
Header Line as a Work Area). When you use internal tables with header lines, you must remember that the header line and the body of the
table have the same name. If you have an internal table with header line and you want to address the body of the table, you must indicate
this by placing brackets after the table name (<itab>[]). Otherwise, ABAP interprets the name as the name of the header line and not of the
body of the table. You can avoid this potential confusion by using internal tables without header lines. In particular, internal tables nested
in structures or other internal tables must not have a header line, since this can lead to ambiguous expressions.
TYPES VECTOR TYPE SORTED TABLE OF I WITH UNIQUE KEY TABLE LINE.
DATA: ITAB TYPE VECTOR,
JTAB LIKE ITAB WITH HEADER LINE.
MOVE ITAB TO JTAB. <- Syntax error!
MOVE ITAB TO JTAB[].
The table object ITAB is created with reference to the table type VECTOR. The table object JTAB has the same data type as ITAB. JTAB also
has a header line. In the first MOVE statement, JTAB addresses the header line. Since this has the data type I, and the table type of ITAB
cannot be converted into an elementary type, the MOVE statement causes a syntax error. The second MOVE statement is correct, since
both operands are table objects.
Declaring New Internal Tables
You can use the DATA statement to construct new internal tables as well as using the LIKE or TYPE addition to refer to existing types or
objects. The table type that you construct does not exist in its own right; instead, it is only an attribute of the table object. You can refer to
it using the LIKE addition, but not using TYPE. The syntax for constructing a table object in the DATA statement is similar to that for defining
a table type in the TYPES statement.
DATA <itab> TYPE|LIKE <tabkind> OF <linetype> WITH <key>
[INITIAL SIZE <n>]
[WITH HEADER LINE].
As when you define a table type , the type constructor
<tabkind> OF <linetype> WITH <key>
defines the table type <tabkind>, the line type <linekind>, and the key <key> of the internal table <itab>. Since the technical attributes of
data objects are always fully specified, the table must be fully specified in the DATA statement. You cannot create generic table types (ANY
TABLE, INDEX TABLE), only fully-typed tables (STANDARD TABLE, SORTED TABLE, HASHED TABLE). You must also specify the key and whether
it is to be unique (for exceptions, refer to Special Features of Standard Tables).
As in the TYPES statement, you can, if you wish, allocate an initial amount of memory to the internal table using the INITIAL SIZE addition.
You can create an internal table with a header line using the WITH HEADER LINE addition. The header line is created under the same
conditions as apply when you refer to an existing table type.
DATA ITAB TYPE HASHED TABLE OF SPFLI
WITH UNIQUE KEY CARRID CONNID.
The table object ITAB has the type hashed table, a line type corresponding to the flat structure SPFLI from the ABAP Dictionary, and a
unique key with the key fields CARRID and CONNID. The internal table ITAB can be regarded as an internal template for the database table
SPFLI. It is therefore particularly suitable for working with data from this database table as long as you only access it using the key.

Standard & hashed tables

hello every one,
This is rahul
when we are declaring internal table by default it takes as standard table
but y don't we take hashed table they can get performance very well
hashed can perform very well than standard na

hI
READ THIS POINTS
Internal tables are the core of ABAP. They are like soul of a body. For any program we use
internal tables extensively. We can use Internal tables like normal data base tables only, but the
basic difference is the memory allocated for internal tables is temporary. Once the program is
closed the memory allocated for internal tables will also be out of memory.
But while using the internal tables, there are many performance issues to be considered. i.e which
type of internal table to be used for the program..like standard internal table, hashed internal
table or sorted internal table etc..
Internal tables
Internal tables provide a means of taking data from a fixed structure and storing it in working memory in ABAP. The data is stored line by
line in memory, and each line has the same structure. In ABAP, internal tables fulfill the function of arrays. Since they are dynamic data
objects, they save the programmer the task of dynamic memory management in his or her programs. You should use internal tables
whenever you want to process a dataset with a fixed structure within a program. A particularly important use for internal tables is for
storing and formatting data from a database table within a program. They are also a good way of including very complicated data
structures in an ABAP program.
Like all elements in the ABAP type concept, internal tables can exist both as data types and as data objects A data type is the abstract
description of an internal table, either in a program or centrally in the ABAP Dictionary, that you use to create a concrete data object. The
data type is also an attribute of an existing data object.
Internal Tables as Data Types
Internal tables and structures are the two structured data types in ABAP. The data type of an internal table is fully specified by its line type,
key, and table type.
Line type
The line type of an internal table can be any data type. The data type of an internal table is normally a structure. Each component of the
structure is a column in the internal table. However, the line type may also be elementary or another internal table.
Key
The key identifies table rows. There are two kinds of key for internal tables - the standard key and a user-defined key. You can specify
whether the key should be UNIQUE or NON-UNIQUE. Internal tables with a unique key cannot contain duplicate entries. The uniqueness
depends on the table access method.
If a table has a structured line type, its default key consists of all of its non-numerical columns that are not references or themselves
internal tables. If a table has an elementary line type, the default key is the entire line. The default key of an internal table whose line type
is an internal table, the default key is empty.
The user-defined key can contain any columns of the internal table that are not references or themselves internal tables. Internal tables
with a user-defined key are called key tables. When you define the key, the sequence of the key fields is significant. You should remember
this, for example, if you intend to sort the table according to the key.
Table type
The table type determines how ABAP will access individual table entries. Internal tables can be divided into three types:
Standard tables have an internal linear index. From a particular size upwards, the indexes of internal tables are administered as trees. In
this case, the index administration overhead increases in logarithmic and not linear relation to the number of lines. The system can access
records either by using the table index or the key. The response time for key access is proportional to the number of entries in the table.
The key of a standard table is always non-unique. You cannot specify a unique key. This means that standard tables can always be filled
very quickly, since the system does not have to check whether there are already existing entries.
Sorted tables are always saved sorted by the key. They also have an internal index. The system can access records either by using the
table index or the key. The response time for key access is logarithmically proportional to the number of table entries, since the system
uses a binary search. The key of a sorted table can be either unique or non-unique. When you define the table, you must specify whether
the key is to be unique or not. Standard tables and sorted tables are known generically as index tables.
Hashed tables have no linear index. You can only access a hashed table using its key. The response time is independent of the number of
table entries, and is constant, since the system access the table entries using a hash algorithm. The key of a hashed table must be unique.
When you define the table, you must specify the key as UNIQUE.
Generic Internal Tables
Unlike other local data types in programs, you do not have to specify the data type of an internal table fully. Instead, you can specify a
generic construction, that is, the key or key and line type of an internal table data type may remain unspecified. You can use generic
internal tables to specify the types of field symbols and the interface parameters of procedures . You cannot use them to declare data
objects.
Internal Tables as Dynamic Data Objects
Data objects that are defined either with the data type of an internal table, or directly as an internal table, are always fully defined in
respect of their line type, key and access method. However, the number of lines is not fixed. Thus internal tables are dynamic data objects,
since they can contain any number of lines of a particular type. The only restriction on the number of lines an internal table may contain are
the limits of your system installation. The maximum memory that can be occupied by an internal table (including its internal administration)
is 2 gigabytes. A more realistic figure is up to 500 megabytes. An additional restriction for hashed tables is that they may not contain more
than 2 million entries. The line types of internal tables can be any ABAP data types - elementary, structured, or internal tables. The
individual lines of an internal table are called table lines or table entries. Each component of a structured line is called a column in the
internal table.
Choosing a Table Type
The table type (and particularly the access method) that you will use depends on how the typical internal table operations will be most
frequently executed.
Standard tables
This is the most appropriate type if you are going to address the individual table entries using the index. Index access is the quickest
possible access. You should fill a standard table by appending lines (ABAP APPEND statement), and read, modify and delete entries by
specifying the index (INDEX option with the relevant ABAP command). The access time for a standard table increases in a linear relationship
with the number of table entries. If you need key access, standard tables are particularly useful if you can fill and process the table in
separate steps. For example, you could fill the table by appending entries, and then sort it. If you use the binary search option with key
access, the response time is logarithmically proportional to the number of table entries.
Sorted tables
This is the most appropriate type if you need a table which is sorted as you fill it. You fill sorted tables using the INSERT statement. Entries
are inserted according to the sort sequence defined through the table key. Any illegal entries are recognized as soon as you try to add
them to the table. The response time for key access is logarithmically proportional to the number of table entries, since the system always
uses a binary search. Sorted tables are particularly useful for partially sequential processing in a LOOP if you specify the beginning of the
table key in the WHERE condition.
Hashed tables
This is the most appropriate type for any table where the main operation is key access. You cannot access a hashed table using its index.
The response time for key access remains constant, regardless of the number of table entries. Like database tables, hashed tables always
have a unique key. Hashed tables are useful if you want to construct and use an internal table which resembles a database table or for
processing large amounts of data.
Creating Internal Tables
Like other elements in the ABAP type concept, you can declare internal tables as abstract data
types in programs or in the ABAP Dictionary, and then use them to define data objects.
Alternatively, you can define them directly as data objects. When you create an internal table as a
data object, you should ensure that only the administration entry which belongs to an internal
table is declared statically. The minimum size of an internal table is 256 bytes. This is important if an
internal table occurs as a component of an aggregated data object, since even empty internal
tables within tables can lead to high memory usage. (In the next functional release, the size of the
table header for an initial table will be reduced to 8 bytes). Unlike all other ABAP data objects, you
do not have to specify the memory required for an internal table. Table rows are added to and
deleted from the table dynamically at runtime by the various statements for adding and deleting
records.
You can create internal tables in different types.
You can create standard internal table and then make it sort in side the program.
The same way you can change to hashed internal tables also.
There will be some performance issues with regard to standard internal tables/ hashed internal
tables/ sorted internal tables.
Internal table types
This section describes how to define internal tables locally in a program. You can also define internal tables globally as data types in the
ABAP Dictionary.
Like all local data types in programs , you define internal tables using the TYPES statement. If you do not refer to an existing table type
using the TYPE or LIKE addition, you can use the TYPES statement to construct a new local internal table in your program.
TYPES <t> TYPE|LIKE <tabkind> OF <linetype> [WITH <key>]
[INITIAL SIZE <n>].
After TYPE or LIKE, there is no reference to an existing data type. Instead, the type constructor occurs:
<tabkind> OF <linetype> [WITH <key>]
The type constructor defines the table type <tabkind>, the line type <linetype>, and the key <key> of the internal table <t>.
You can, if you wish, allocate an initial amount of memory to the internal table using the INITIAL SIZE addition.
Table type
You can specify the table type <tabkind> as follows:
Generic table types
INDEX TABLE
For creating a generic table type with index access.
ANY TABLE
For creating a fully-generic table type.
Data types defined using generic types can currently only be used for field symbols and for interface parameters in procedures . The generic
type INDEX TABLE includes standard tables and sorted tables. These are the two table types for which index access is allowed. You cannot
pass hashed tables to field symbols or interface parameters defined in this way. The generic type ANY TABLE can represent any table. You
can pass tables of all three types to field symbols and interface parameters defined in this way. However, these field symbols and
parameters will then only allow operations that are possible for all tables, that is, index operations are not allowed.
Fully-Specified Table Types
STANDARD TABLE or TABLE
For creating standard tables.
SORTED TABLE
For creating sorted tables.
HASHED TABLE
For creating hashed tables.
Fully-specified table types determine how the system will access the entries in the table in key operations. It uses a linear search for
standard tables, a binary search for sorted tables, and a search using a hash algorithm for hashed tables.
Line type
For the line type <linetype>, you can specify:
Any data type if you are using the TYPE addition. This can be a predefined ABAP type, a local type in the program, or a data type from the
ABAP Dictionary. If you specify any of the generic elementary types C, N, P, or X, any attributes that you fail to specify (field length, number
of decimal places) are automatically filled with the default values. You cannot specify any other generic types.
Any data object recognized within the program at that point if you are using the LIKE addition. The line type adopts the fully-specified data
type of the data object to which you refer. Except for within classes, you can still use the LIKE addition to refer to database tables and
structures in the ABAP Dictionary (for compatibility reasons).
All of the lines in the internal table have the fully-specified technical attributes of the specified data type.
Key
You can specify the key <key> of an internal table as follows:
[UNIQUE|NON-UNIQUE] KEY <col1> ... <col n>
In tables with a structured line type, all of the components <coli> belong to the key as long as they are not internal tables or references,
and do not contain internal tables or references. Key fields can be nested structures. The substructures are expanded component by
component when you access the table using the key. The system follows the sequence of the key fields.
[UNIQUE|NON-UNIQUE] KEY TABLE LINE
If a table has an elementary line type (C, D, F, I, N, P, T, X), you can define the entire line as the key. If you try this for a table whose line
type is itself a table, a syntax error occurs. If a table has a structured line type, it is possible to specify the entire line as the key. However,
you should remember that this is often not suitable.
[UNIQUE|NON-UNIQUE] DEFAULT KEY
This declares the fields of the default key as the key fields. If the table has a structured line type, the default key contains all non-numeric
columns of the internal table that are not and do not contain references or internal tables. If the table has an elementary line type, the
default key is the entire line. The default key of an internal table whose line type is an internal table, the default key is empty.
Specifying a key is optional. If you do not specify a key, the system defines a table type with an arbitrary key. You can only use this to
define the types of field symbols and the interface parameters of procedures . For exceptions, refer to Special Features of Standard Tables.
The optional additions UNIQUE or NON-UNIQUE determine whether the key is to be unique or non-unique, that is, whether the table can
accept duplicate entries. If you do not specify UNIQUE or NON-UNIQUE for the key, the table type is generic in this respect. As such, it can
only be used for specifying types. When you specify the table type simultaneously, you must note the following restrictions:
You cannot use the UNIQUE addition for standard tables. The system always generates the NON-UNIQUE addition automatically.
You must always specify the UNIQUE option when you create a hashed table.
Initial Memory Requirement
You can specify the initial amount of main memory assigned to an internal table object when you define the data type using the following
addition:
INITIAL SIZE <n>
This size does not belong to the data type of the internal table, and does not affect the type check. You can use the above addition to
reserve memory space for <n> table lines when you declare the table object.
When this initial area is full, the system makes twice as much extra space available up to a limit of 8KB. Further memory areas of 12KB each
are then allocated.
You can usually leave it to the system to work out the initial memory requirement. The first time you fill the table, little memory is used. The
space occupied, depending on the line width, is 16 <= <n> <= 100.
It only makes sense to specify a concrete value of <n> if you can specify a precise number of table entries when you create the table and
need to allocate exactly that amount of memory (exception: Appending table lines to ranked lists). This can be particularly important for
deep-structured internal tables where the inner table only has a few entries (less than 5, for example).
To avoid excessive requests for memory, large values of <n> are treated as follows: The largest possible value of <n> is 8KB divided by the
length of the line. If you specify a larger value of <n>, the system calculates a new value so that n times the line width is around 12KB.
Examples
TYPES: BEGIN OF LINE,
COLUMN1 TYPE I,
COLUMN2 TYPE I,
COLUMN3 TYPE I,
END OF LINE.
TYPES ITAB TYPE SORTED TABLE OF LINE WITH UNIQUE KEY COLUMN1.
The program defines a table type ITAB. It is a sorted table, with line type of the structure LINE and a unique key of the component
COLUMN1.
TYPES VECTOR TYPE HASHED TABLE OF I WITH UNIQUE KEY TABLE LINE.
TYPES: BEGIN OF LINE,
COLUMN1 TYPE I,
COLUMN2 TYPE I,
COLUMN3 TYPE I,
END OF LINE.
TYPES ITAB TYPE SORTED TABLE OF LINE WITH UNIQUE KEY COLUMN1.
TYPES: BEGIN OF DEEPLINE,
FIELD TYPE C,
TABLE1 TYPE VECTOR,
TABLE2 TYPE ITAB,
END OF DEEPLINE.
TYPES DEEPTABLE TYPE STANDARD TABLE OF DEEPLINE
WITH DEFAULT KEY.
The program defines a table type VECTOR with type hashed table, the elementary line type I and a unique key of the entire table line. The
second table type is the same as in the previous example. The structure DEEPLINE contains the internal table as a component. The table
type DEEPTABLE has the line type DEEPLINE. Therefore, the elements of this internal table are themselves internal tables. The key is the
default key - in this case the column FIELD. The key is non-unique, since the table is a standard table.
Internal table objects
Internal tables are dynamic variable data objects. Like all variables, you declare them using the DATA statement. You can also declare static
internal tables in procedures using the STATICS statement, and static internal tables in classes using the CLASS-DATA statement. This
description is restricted to the DATA statement. However, it applies equally to the STATICS and CLASS-DATA statements.
Reference to Declared Internal Table Types
Like all other data objects, you can declare internal table objects using the LIKE or TYPE addition of the DATA statement.
DATA <itab> TYPE <type>|LIKE <obj> [WITH HEADER LINE].
Here, the LIKE addition refers to an existing table object in the same program. The TYPE addition can refer to an internal type in the
program declared using the TYPES statement, or a table type in the ABAP Dictionary.
You must ensure that you only refer to tables that are fully typed. Referring to generic table types (ANY TABLE, INDEX TABLE) or not
specifying the key fully is not allowed (for exceptions, refer to Special Features of Standard Tables).
The optional addition WITH HEADER line declares an extra data object with the same name and line type as the internal table. This data
object is known as the header line of the internal table. You use it as a work area when working with the internal table (see Using the
Header Line as a Work Area). When you use internal tables with header lines, you must remember that the header line and the body of the
table have the same name. If you have an internal table with header line and you want to address the body of the table, you must indicate
this by placing brackets after the table name (<itab>[]). Otherwise, ABAP interprets the name as the name of the header line and not of the
body of the table. You can avoid this potential confusion by using internal tables without header lines. In particular, internal tables nested
in structures or other internal tables must not have a header line, since this can lead to ambiguous expressions.
TYPES VECTOR TYPE SORTED TABLE OF I WITH UNIQUE KEY TABLE LINE.
DATA: ITAB TYPE VECTOR,
JTAB LIKE ITAB WITH HEADER LINE.
MOVE ITAB TO JTAB. <- Syntax error!
MOVE ITAB TO JTAB[].
The table object ITAB is created with reference to the table type VECTOR. The table object JTAB has the same data type as ITAB. JTAB also
has a header line. In the first MOVE statement, JTAB addresses the header line. Since this has the data type I, and the table type of ITAB
cannot be converted into an elementary type, the MOVE statement causes a syntax error. The second MOVE statement is correct, since
both operands are table objects.
Declaring New Internal Tables
You can use the DATA statement to construct new internal tables as well as using the LIKE or TYPE addition to refer to existing types or
objects. The table type that you construct does not exist in its own right; instead, it is only an attribute of the table object. You can refer to
it using the LIKE addition, but not using TYPE. The syntax for constructing a table object in the DATA statement is similar to that for defining
a table type in the TYPES statement.
DATA <itab> TYPE|LIKE <tabkind> OF <linetype> WITH <key>
[INITIAL SIZE <n>]
[WITH HEADER LINE].
As when you define a table type , the type constructor
<tabkind> OF <linetype> WITH <key>
defines the table type <tabkind>, the line type <linekind>, and the key <key> of the internal table <itab>. Since the technical attributes of
data objects are always fully specified, the table must be fully specified in the DATA statement. You cannot create generic table types (ANY
TABLE, INDEX TABLE), only fully-typed tables (STANDARD TABLE, SORTED TABLE, HASHED TABLE). You must also specify the key and whether
it is to be unique (for exceptions, refer to Special Features of Standard Tables).
As in the TYPES statement, you can, if you wish, allocate an initial amount of memory to the internal table using the INITIAL SIZE addition.
You can create an internal table with a header line using the WITH HEADER LINE addition. The header line is created under the same
conditions as apply when you refer to an existing table type.
DATA ITAB TYPE HASHED TABLE OF SPFLI
WITH UNIQUE KEY CARRID CONNID.
The table object ITAB has the type hashed table, a line type corresponding to the flat structure SPFLI from the ABAP Dictionary, and a
unique key with the key fields CARRID and CONNID. The internal table ITAB can be regarded as an internal template for the database table
SPFLI. It is therefore particularly suitable for working with data from this database table as long as you only access it using the key.

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.com

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.com

WPF UI running in seperate runspace - able to set/get controls via synchronized hash table, but referencing the control via the hash table from within an event handler causes both runspaces to hang.

I am trying to build a proof of concept where a WPF form is hosted in a seperate runspace and updates are handled from the primary shell/runspace. I have had some success thanks to a great article by Boe Prox, but I am having an issue I wanted to open up
to see if anyone had a suggestion.
My goals are as follows:
1.) Set control properties from the primary runspace (Completed)
2.) Get control properties from the primary runspace (Completed)
3.) Respond to WPF form events in the UI runspace from the primary runspace (Kind of broken).
I have the ability to read/write values to the form, but I am having difficulty with events. Specifically, I can fire and handle events, but the minute I try to reference the $SyncHash from within the event it appears to cause a blocking condition hanging both
runspaces. As a result, I am unable to update the form based on an event being fired by a control.
In the example below, the form is loaded and the following steps occur:
1.) Update-Combobox is called and it populates the combobox with a list of service names and selects the first item.
2.) update-textbox is called and sets the Text property of the textbox.
3.) The Text value of the textbox is read by the function read-textbox and output using write-host.
4.) An event handle is registered for the SelectionChanged event for the combobox to call the update-textbox function used earlier.
5.) If you change the selection on the combobox, the shell and UI hangs as soon as $SyncHash is referenced. I suspect this is causing some sort of blocking condition from multiple threads trying to access the synchronized nature of the hash table, but I am
unsure as to why / how to work around it. If you comment out the line "$SyncHash.TXT_Output.Dispatcher.Invoke("Send",[action]{$SyncHash.TXT_Output.Text = $Value})" within update-textbox the event handler will execute/complete.
$UI_JobScript =
try{
Function New-Form ([XML]$XAML_Form){
$XML_Node_Reader=(New-Object System.Xml.XmlNodeReader $XAML_Form)
[Windows.Markup.XamlReader]::Load($XML_Node_Reader)
try{
Add-Type –AssemblyName PresentationFramework
Add-Type –AssemblyName PresentationCore
Add-Type –AssemblyName WindowsBase
catch{
Throw "Unable to load the requisite Windows Presentation Foundation assemblies. Please verify that the .NET Framework 3.5 Service Pack 1 or later is installed on this system."
$Form = New-Form -XAML_Form $SyncHash.XAML_Form
$SyncHash.Form = $Form
$SyncHash.CMB_Services = $SyncHash.Form.FindName("CMB_Services")
$SyncHash.TXT_Output = $SyncHash.Form.FindName("TXT_Output")
$SyncHash.Form.ShowDialog() | Out-Null
$SyncHash.Error = $Error
catch{
write-host $_.Exception.Message
#End UI_JobScript
#Begin Main
add-type -AssemblyName WindowsBase
[XML]$XAML_Form = @"
<Window xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<Window.Resources>
<DataTemplate x:Key="DTMPL_Name">
<TextBlock Text="{Binding Path=Name}" />
</DataTemplate>
</Window.Resources>
<DockPanel LastChildFill="True">
<StackPanel Orientation="Horizontal" DockPanel.Dock="Top">
<Label Name="LBL_Services" Content="Services:" />
<ComboBox Name="CMB_Services" ItemTemplate="{StaticResource DTMPL_Name}"/>
</StackPanel>
<TextBox Name="TXT_Output"/>
</DockPanel>
</Window>
$SyncHash = [hashtable]::Synchronized(@{})
$SyncHash.Add("XAML_Form",$XAML_Form)
$SyncHash.Add("InitialScript", $InitialScript)
$Normal = [System.Windows.Threading.DispatcherPriority]::Normal
$UI_Runspace =[RunspaceFactory]::CreateRunspace()
$UI_Runspace.ApartmentState = [System.Threading.ApartmentState]::STA
$UI_Runspace.ThreadOptions = [System.Management.Automation.Runspaces.PSThreadOptions]::ReuseThread
$UI_Runspace.Open()
$UI_Runspace.SessionStateProxy.SetVariable("SyncHash",$SyncHash)
$UI_Pipeline = [PowerShell]::Create()
$UI_Pipeline.Runspace=$UI_Runspace
$UI_Pipeline.AddScript($UI_JobScript) | out-Null
$Job = $UI_Pipeline.BeginInvoke()
$SyncHash.ServiceList = get-service | select name, status | Sort-Object -Property Name
Function Update-Combobox{
write-host "`nBegin Update-Combobox [$(get-date)]"
$SyncHash.CMB_Services.Dispatcher.Invoke($Normal,[action]{$SyncHash.CMB_Services.ItemsSource = $SyncHash.ServiceList})
$SyncHash.CMB_Services.Dispatcher.Invoke($Normal,[action]{$SyncHash.CMB_Services.SelectedIndex = 0})
write-host "`End Update-Combobox [$(get-date)]"
Function Update-Textbox([string]$Value){
write-host "`nBegin Update-Textbox [$(get-date)]"
$SyncHash.TXT_Output.Dispatcher.Invoke("Send",[action]{$SyncHash.TXT_Output.Text = $Value})
write-host "End Update-Textbox [$(get-date)]"
Function Read-Textbox(){
write-host "`nBegin Read-Textbox [$(get-date)]"
$SyncHash.TXT_Output.Dispatcher.Invoke($Normal,[action]{$Global:Return = $SyncHash.TXT_Output.Text})
$Global:Return
remove-variable -Name Return -scope Global
write-host "End Read-Textbox [$(get-date)]"
#Give the form some time to load in the other runspace
$MaxWaitCycles = 5
while (($SyncHash.Form.IsInitialized -eq $Null)-and ($MaxWaitCycles -gt 0)){
Start-Sleep -Milliseconds 200
$MaxWaitCycles--
Update-ComboBox
Update-Textbox -Value $("Initial Load: $(get-date)")
Write-Host "Value Read From Textbox: $(Read-TextBox)"
Register-ObjectEvent -InputObject $SyncHash.CMB_Services -EventName SelectionChanged -SourceIdentifier "CMB_Services.SelectionChanged" -action {Update-Textbox -Value $("From Selection Changed Event: $(get-date)")}

Thanks again for the responses. This may not be possible, but I thought I would throw it out there. I appreciate your help in looking into this.
To clarify the "Respond to control events in the main runspace"... I'm would like to have an event generated by a form object in the UI runspace (ex: combo box selectionchanged event) trigger a delegate within the main runspace and have that delegate in
the main runspace update the form in the UI runspace.
ex:
1.) User changes selection on combo box generating form event
2.) Event calls delegate (which I have gotten to work)
3.) Delegate does some basic processing (works)
4.) Delegate attempts to update form in UI runspace (hangs)
As to the delegates / which runspace they are running in. I see the $synchash variable if I run get-var within a delegate, but I do not see the $Form variable so I am assuming that they are in the main runspace. Do you agree with that assumption?

RE: (forte-users) Hash tables vs 'sparse' arrays

Similar Messages

Maybe you are looking for