Just a Typical RDM Embedded 10.0 User

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