How to read records after delete in rms in j2me midlet?

Question

I am using rms concept in my j2me application.

Frst records added to rms successfully, then read records also fine but when I am going to add another one record at a same time, that will not be added in my list, it was added to rms successfully but not refreshed that time.

If I go to exit the application once then run the application that records reads well, all the records display. How to refresh the list and get all the records?

This is my source for add records:

public void AddCustomer(String str) throws RecordStoreNotOpenException
{       
    byte[] rec=str.getBytes();
    try
    {
        rs19 = RecordStore.openRecordStore(ADDREMOVE_CUSTOMER, true);
        rs19.addRecord(rec, 0, rec.length);
        System.out.println("REcord added successfully");
        v.addElement(str);
    }
    catch (Exception e)
    {
    }
}

This is source for read records:

public ChoiceGroup getChoiceGroup10() {
    if (choiceGroup10 == null) {                                   
        choiceGroup10 = new ChoiceGroup("Select Customer", Choice.POPUP);                                     
        choiceGroup10.append("none", null);       
        try
        {
            rs19.openRecordStore(ADDREMOVE_CUSTOMER, true);
            String value="";
            String comma=",";
            Vector v1=new Vector();
            StringBuffer enumList=new StringBuffer();
            recEnum = rs19.enumerateRecords( null, null, false );
    while( recEnum.hasNextElement() )
            {
                byte[] data = recEnum.nextRecord();
                enumList.append(new String(data));
                enumList.append(",");
            }
            records=new String(enumList);
            int index=records.indexOf(comma);
            while(index>=0)
            {
                v1.addElement(records.substring(0,index));
                records = records.substring(index+comma.length());
                index = records.indexOf(comma);
            }
            v1.addElement( records );
            if( v1.size()>0 )
            {
                for(int i=0; i<v1.size(); i++)
                {
                    value= (String)v1.elementAt(i);
                    choiceGroup10.append(value, null);
                }
            }
        }
        catch(InvalidRecordIDException ie)
        {
            ie.printStackTrace();
        }
        catch(RecordStoreException re)
        {
            re.printStackTrace();
        }
        catch(NullPointerException ne)
        {
            System.out.println(ne);
        }
        finally
        {
            try {
                rs19.closeRecordStore();
            } catch (RecordStoreException ex) {
                ex.printStackTrace();
            }
        }

    }                          
    return choiceGroup10;
}

score 1 · Answer 1 · edited Jul 21 '12 at 12:00

  recEnum = rs19.enumerateRecords( null, null, false ); // --> keepUpdated is false

The way you describe, added to rms successfully but not refreshed that time appears to be defined by the third parameter passed to enumerateRecords.

To understand why is that and learn how to use method parameters, refer to API documentation (available online) - note explanation for keepUpdated parameter:

public RecordEnumeration enumerateRecords(RecordFilter filter,
                                          RecordComparator comparator,
                                          boolean keepUpdated)
                                   throws RecordStoreNotOpenException

    Returns an enumeration for traversing a set of records in the record store
      in an optionally specified order...

    Parameters:
        filter - if non-null, will be used to determine what subset
          of the record store records will be used
        comparator - if non-null, will be used to determine the order
          in which the records are returned
        keepUpdated - if true, the enumerator will keep its enumeration
          current with any changes in the records of the record store.
          Use with caution as there are possible performance consequences.
          If false the enumeration will not be kept current and may return
          recordIds for records that have been deleted or miss records
          that are added later. It may also return records out of order
          that have been modified after the enumeration was built.
          Note that any changes to records in the record store are
          accurately reflected when the record is later retrieved,
          either directly or through the enumeration. The thing that is
          risked by setting this parameter false is the filtering and
          sorting order of the enumeration when records are modified,
          added, or deleted.
          ...

Given above, consider testing your MIDlet with another value of keepUpdated parameter:

  recEnum = rs19.enumerateRecords(null, null, true); // --> test with 'true' here

i have try your suggestion also, but not getting. – cheliyan Jul 21 '12 at 09:34 — cheliyan, Jul 21 '12 at 09:34

score 1 · Answer 2 · edited May 23 '17 at 11:48

Although gnat is entirely correct, there are good reasons why nobody uses the keepUpdated parameter (reliance on a very bad part of the MIPD specification, loss of control over synchronization...).

If you want to control the behavior of your application, keepUpdated should remain false and your AddCustomer() method should close the RecordStore.

Then you need a mechanism that triggers an update of your GUI (by re-executing your entire getChoiceGroup10() method and displaying the new result on the screen) because AddCustomer() was called successfully. In order to do that properly, you need a deep understanding of your GUI threading model. Do you use LWUIT? Did you create a thread just for your GUI? Is the GUI only refreshed when necessary or does it have a frame rate?

Based on that understanding, you will either use a listener interface, use synchronization, set a flag to update a part of the screen later...

Typically you would not want the thread that draws on the screen to also read from a RecordStore so you may actually end up rewriting your getChoiceGroup10() method in order to split its content over 2 threads.

How to read records after delete in rms in j2me midlet?

2 Answers2