Lilac Ezer

The Smart Ticket application (J2ME Blueprints) has some decent design patterns related to RMS. Since you are storing unsorted binary data, your record filter needs to read some part of that data from every record to be able to select the appropriate records. You need to really think about the order your serialized data is stored, and use the smallest datatypes you can for searchable fields. In Smart Ticket, there is a single RMS datastore that holds all the data (of different types of information), and another datastore called Index which is used to look up data by type, and references the recordId of the corresponding data row. I think this is similar to the concept of unclustered indexes in RDBMS to look up data.
To optimize RMS calls in your application, you may also want to perform data operations in separate threads (if appropriate), or buffer/flush search results to the screen as they are found.
I'd be interested in hearing what other patterns j2me developers have implemented for dealing with RMS.
Lilac Ezer
www.codealloy.com

As far as I know, information such as cellphone number, address book, calendar, etc, are not part of the MIDP specification. You may access such information by using APIs from the cellphone providers (I believe Nokia has an SDK that gives you access to some of that information, but only on certain phone models).

I'm not sure why you need to use a DataSource to get the Connection. Here is how you can create a connection manually (SQL Server example):
Class.forName("com.microsoft.jdbc.sqlserver.SQLServerDriver");
Connection con = DriverManager.getConnection("jdbc:microsoft:sqlserver://" + server +
":" + port + ";DatabaseName=Master;", username, password);

Did you try to add ojdbc14.jar explicity to the end of your CLASSPATH environment variable?

Here is the syntax for getting the number of user-defined tables in the database you are currently in:
select count(*) from sysobjects where type='U'
Hope that helps,
Lilac

You said that when you take out the Output parameter, this works. It may be required with this JDBC driver to register the Output param as follows:
CallableStatement cs......
cs.registerOutParameter(10, Types.INTEGER);

java:comp/env is simply the root context for JNDI mappings you declare in your application. If you define a JDBC connection mapped to JNDI name jdbc/myDB, then you can access it through the context java:comp/env/jdbc/myDB. You never need to worry about defining java:comp/env anywhere. Some application servers (like JRun) will not require you to enter java:comp/env when performing a lookup, so check the documentation of your specific J2EE server for more information on JNDI names.

I think the preferred solution is to declare your properties in the EJB deployment descriptors in <env-entry> elements.
I think if you called getResource or used the Preferences API in jdk1.4, that is still 'cheating' because I/O calls may still take place, even if you are not calling a file directly.