J2ME jsr-75 commit issues

[markusSV]

Hello,
I am developing a PIM-based application and encountering the following problems on SIM :

On Nokia/Series40 3RD FP1 devices ( ANY of these, not reproductible on others ).


When trying to commit a SIM Contact ( having less than SIM MAX Capacity Contacts),

javax.microedition.pim.PIMException: Error writing to contact DB, error=0x80000021

Please note that this exception is different than when the SIM Card is full -
javax.microedition.pim.PIMException: Error writing to contact DB, error=0x8000002f


Please tell me what error code 0x80000021 reffers to and what should i do to make it work.

Also, please note that the API does not rollback the operation ( it should rollback ).
The committed item is available from next reopening of PIMList on SIM folder. Still, this is an altered item, and the ID is unavailable ( -1 ) if you don't reopen the PIMList.
When seeking for the item after the exception occurs and reopening the PIMList.

Assume :

aCommittedNew = newContact.commit();

PIMItems[] items = SIMContactList.items(aCommittedNew);// does not always return the altered item. I am unable to rollback successfully due to these issues.

Additional details :

- A full-field SIM Contact is used ( This means it has Phone Number and Name only !).
- There are no dummy datas in the Contact ( 2-3 chars for Name and 9 numbers for Phone Number )
- This exception occurs unpredictable. This means, if you add and remove a Contact it in a loop, it may or may not occur.

Please ask for any additional informations you may need to help me solve this issue. I consider it a 3RD Party JSR-75 issue. HELP!

Foot note : I have J2ME and jsr-75 experience. Please assume my code is correct.
Thanks!

[hartti]

This is purely a guess...but...

You said that you are doing the adding and removing of contacts in a loop. Could you add some wait time in the loop and see if the error still exists... (I am guessing that this could happen because the SIM card is not ready for new write/edit. And no, I did not yet find any information about that specific error code)

Hartti

[markusSV]

Hello hartti, and thanks for your reply.

I am not doing the commits in a loop, there are plenty other operations executed between commits. I've been thinking of this possibility also, but didn't give it a try yet. Still, on other Nokia devices the SIM is ready for new read/write operations and everything works perfectly.

However, this is reproducing only on S403RD FP1.

When i said it is reproductible in a loop, i mean that's an easy way to reproduce rather than creating any complex things like i have.

In my executions, it's like committing n contacts one after another, these contacts being deserialized from a vCard first plus extra operations.

I've noticed that on a static vCard the exception may or may not reproduce. It's just unpredictable and weird. I'd like to know more about it and how to fix.

I will give it a try tomorrow, and use a delay.

If it doesn't work, i will prepare a test MIDlet to gather and provide further details.

Thanks again,
Markus.

[markusSV]

It seems that any delay used does not fully remove the issue. I've tried times up to 1 second. However, the exception launches less than without any delay. But still, this does not solve the problem.

I'm looking forward for answers.

Thanks,
Markus.

[hartti]

Ok, sorry for the misunderstanding. As said, that was purely a guess.

If you have some kind of test MIDlet, you could send it to me (guessing my email address should not be too hard, lastname dot firstname etc...)
I likely do not have time to go through that myself, but I'll try to find some other resources for this.

Hartti Suomela
Forum Nokia

[markusSV]

Thanks again for trying to help me with this, but i figured it out today.

I've been writing the test application and tested some different vCards.

The problem was that if you didn't use the vCard fields like it generates when you serialize an item, it could fail unpredictable.

Example :

I was trying to import vCards like :

BEGIN:VCARD
VERSION:2.1
FN:fn_x
TEL:123x
END:VCARD

Using FN and TEL fields resulted in that exception for an unpredictable amount of contacts. However, it succeeded for some ( Lower than 10% of the contacts ).

The format that doesn't throw any exception is :

BEGIN:VCARD
VERSION:2.1
N:fn_x
TEL;PREF;VOICE:123x
END:VCARD

This is a workaround, but i can live with it. Normally things like this shouldn't happen because the PIM documentation says clearly that when you commit an item, only supported fields will be imported. Also the native import must know how to map the fields from a full vCard to a restricted vCard ( Phone-> SIM ), as the version of the vCard is the same. It looks like he maps correctly, but not every time. Weird.

Markus.

[markusSV]

I was too happy when i seen the commits working. But after checking them, the name is missing.

Looks like the correct vCard is still with these fields
FN:value;
TEL:value

Changing FN to N resulted in silently ignoring the Name field. Seems like, if the Name is present, commit fails.

I've added commit delay and commit retry features to the test MIDlet. Seems like it still fails for 25% of the contacts with a retry count of 10 for each problematic item.

I'll continue my investigations.

[hartti]

Are there any commonalities (like same characters, etc) between the FN fields of the items which fail initially?
And with the comment on retries I guess you mean that if you just try and try, finally also the problematic items will be inserted?

Hartti

[markusSV]

That is correct, hartti.

The used Contacts were :
FN:FN1..100
TEL:1234

There are no special chars around.

If you retry and retry over and over it will definitely succeed. But 10 retries are not guaranteeing the success of the commit.

If i put it recursive retry, with unlimited count ( Which is not a good idea ), it commits correctly. But the performance footprint is enormously damaged. The commit time for 100 contacts becomes a few hours. Which is not acceptable.

Also, threading the operation or delaying it does not give any result. It's just the same as continously doing it in the same thread.


Also, please note that the problematic items are saved on SIM and can be seen from native address book if not deleted, only that the exception launches. But i must guarantee the success fo the operation so that's why i have to rollback and retry.

[chaimkut]

Hi

I've encountered this same problem recently except with a slightly different error code:

Error writing to contact DB, error=0x80000021retryCount = 0

I'm attempting to write a picture to Contact.PHOTO to a contact in the phone's memory. I first attempt to write the pure JPEG as a binary field and if that fails, I try to enode into Base64 (using Stefan Haustein's) and then write.

Have you had any success in resolving the problem (besides for simply retrying repeatedly)?

[markusSV]

Hello chaimkut,

I could first ask you if your device supports PHOTO first at all, and if you use isSupportedField prior to adding the data.

I didn't experience this issue yet as my problem was related to SIM.

However, i couldn't find another 100% fix for the issue, just the remove/retry or update.

I solved this issue by separating the add operation in two steps :

first, id reservation :

Contact contact = contactList.createContact();
contact.commit(); // now id is reserved;

/*custom method for pimitems to update*/
Second, updating
overwrite(newContact, contact);
contact.commit();// commit changes; retry if fails

[heeb]

This is still unanswered:

I also get

Error writing to contact DB, error=0x80000021retryCount = 0

when writing an image to a contact. The phone (6212 NFC phone) DOES support image writing because I did it before. Could it be that images have a max. size? Could it be that Sys60 phone take any image and resize but Sys40 only accept some sizes?

Hans

[heeb]

To answer my own question, the following works for me:

If the error happens, abort the thread and redo everything (open PIM list, get contacts, find right contact, write to the contact that failed). Each such redo only does a single contact, then the error happens again. Painful.

BTW this seems to affect all Sys40 Ed5, Ed6 seems ok

Hans