Wednesday, February 9, 2011

“Just a Typical RDM Embedded 10.0 User”

By Randy Merilatt, Raima CTO

Before I fully take on the CTO role, I am still in the process of discharging my final responsibilities as the principal developer of the new SQL for RDM Embedded (RDMe). In this blog article, I want to relate some of the experiences I have had as a software engineer who uses RDMe. Now, granted, I am not what one would consider an objective user. I am unabashedly biased. Moreover, I am an expert in the use of RDMe. After all, I was one of the original developers of the product. However, I have had no engineering involvement in its development for many years now and am now a user of the product of the engineering effort of others. So, what I am about to share is true and I do not exaggerate.

SQL is essentially just an RDMe application program. While we have added some new core API functions to the RDMe runtime in order to support the needs of SQL, those new functions will be available to all users so that there is nothing that SQL utilizes from RDMe that is not available to everyone. Since, at the time of this writing, SQL is still under development, I must state that my use of RDMe has been primarily in a test and debug mode. That’s not to say that there hasn’t been some intensive RDMe use, however, as one of the example databases that is referenced in the new SQL User’s Guide contains several tables (record types) each containing well over 100,000 rows (record occurrences). To give you some idea of the breadth of RDMe runtime usage, the table at the end of this article shows all of the core API functions that are used in SQL. SQL also uses many of the RDMe PSP (Platform Support Package) functions.

The version of RDMe being used is the new version that will be released with SQL. It is based on RDMe 10.0. I have performed my testing using one or more (when testing database unions) RDMe Transactional File Servers (TFS) running as separate processes on my quad-core Windows 7 computer. In all of the testing I have done so far, I have encountered many bugs in my own (new) code but I have encountered very few bugs in the RDMe runtime. In fact, the only bugs I have encountered have been in the new functionality that is being added to the RDMe runtime to support SQL (subsequently fixed, by the way). I have had no problems whatsoever in my use of the RDMe 10.0 system. It has operated for me with very good performance and high reliability. In fact, this also seems to be true of our other RDMe 10.0 users. Since its release last July, we have had very few reports of any problems with it from our users—a credit to the great work put in by the Raima Q/A team.

I have come to love the TFS architecture because it has yet to crash. SQL has crashed often during debug sessions (the inevitable memory fault, etc.), but the TFS simply recognizes the disconnection and continues to run. Because the RDMe runtime is separate from the TFS, it is much more difficult for an application to corrupt the database (not impossible, just more difficult). I have not yet had any database corruption occur in my testing and debugging of SQL.

I also love the read-only transaction capability and have incorporated its use into the new SQL’s select statement processing. When read-only transaction mode is used, executing a select statement will automatically issue d_trrobegin call instead of issuing the needed table read locks. No locks are needed and no blocking of any database operations occur. It is very fast, and very clean.

If you are an RDM Embedded user and you have not yet decided to upgrade to version 10.0, let me encourage you to do so. Explore the capabilities that the new TFS architecture provides. The flexibility and reliability you will gain, I believe, is well worth it. You can download it from here: http://www.raima.com/products/rdm-embedded/sdk-download/.

List of RDMe Core API Functions with X Indicating those Used in SQL

d_blobdelete

X

d_findnm

X

d_recfrst

X

d_blobread

X

d_findpm

X

d_reclast

d_blobseek

d_fldnum

d_reclock

d_blobsize

X

d_freeall

X

d_reclstat

X

d_blobtell

d_iclose

d_recnext

X

d_blobtruncate

d_initfile

d_recnum

d_blobwrite

X

d_initialize

X

d_recprev

d_close

X

d_internals

d_recread

X

d_closetask

X

d_iopen

X

d_recset

X

d_cmtype

d_iopen_ptr

X

d_rectot

X

d_connect

X

d_ismember

X

d_recwrite

X

d_cotype

d_isowner

X

d_rerdcurr

d_crget

X

d_keydel

d_set_dberr

X

d_crread

X

d_keydir*

X

d_setdb

d_crset

X

d_keyexist

d_setfree

d_crtype

X

d_keyfind

X

d_setkey

d_crwrite

X

d_keyfree

d_setlock

d_csmget

d_keyfrst

X

d_setlstat

d_csmread

d_keylast

d_setmm

d_csmset

X

d_keylock

d_setmo

d_csmwrite

d_keylstat

d_setmr

X

d_csoget

X

d_keynext

X

d_setnum

d_csoread

X

d_keyprev

X

d_setom

d_csoset

X

d_keyrdstate

X

d_setoo

d_csowrite

d_keyread

X

d_setor

X

d_curkey

d_keystore

d_setpages

d_dberr

d_keyszstate

X

d_setrm

d_dbnum

X

d_keywrstate

X

d_setro

d_dbsetini

d_lmstat

d_timeout

X

d_dbuserid

d_lock

X

d_trabort

X

d_dbver

d_makenew

d_tractive

X

d_decode_dba

X

d_members

d_trbegin

X

d_def_opt

d_off_opt

d_trdeletemark

X

d_delete

X

d_on_opt

d_trend

X

d_destroy

d_open

X

d_trmark

X

d_discon

X

d_open_ptr

X

d_trprecommit

d_disdel

d_opentask

X

d_trrobegin

X

d_encode_dba

d_pkeyfind

X

d_trroend

X

d_fillnew

X

d_pkeynext

X

d_trrollback

X

d_findco

X

d_pkeyprev

d_wrcurr

d_findfm

X

d_rdcurr

d_findlm

d_recfree



* New functions to be released are italicized