Skip to content

Just a Typical RDM Embedded 10.0 User

Chief Technology Officer, Randy Merilatt, discusses the ins and outs of RDM Embedded 10.0. As one of the original developers of the project, Randy talks about new core API functions, RDMe’s addition of SQL and more.

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 is a high availability database. 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.

Download RDM Embedded Now

List of RDMe Core API Functions with X Indicating those Used in SQL
* New functions to be released are italicized
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