Products & Services

• RDM Server
• RDM Embedded
  • What's New
  • Specification
  • Datasheets & Brochures
  • Technical Publications
  • SDK Download
  • Support
  • FAQ
  • Online Documentation
• RDM Mobile
• Support Plans
• Professional Services

RDM Embedded

FAQ

01) How is Birdstep RDM Embedded used?
The database is used wherever applications need fast, accurate data management in embedded and or real time operating environments.

02) Why are Developers choosing Birdstep RDM Embedded?
Birdstep RDM Embedded saves development time by providing a reliable database engine designed for embedding within an application. Installation is easy, and the extensive C library is familiar to C and C++ programmers. This cuts application development costs and improves time-to-market, as developers can concentrate on product rather than in-house database development. Birdstep 's RDM further reduces costs by being highly reliable, easy to maintain, and invisible to the end-user.

03) Why is the database so flexible?
Birdstep RDM Embedded is a compact database engine built around a comprehensive library of C functions for optimum database control. This allows a wide range of customized features with commands that are familiar to C programmers. The records managed by RDM are in a majority of C data types, including arrays and struts.

04) What is the product's history of reliability?
The Birdstep RDM Embedded is a mature product with a long history of successful implementations and has continually been updated to offer the most advanced features. In addition, the C kernel is a proven tool in both wide variety of applications and markets since 1984.

05) How does the database address data integrity?
Birdstep RDM Embedded's lock management system gives control over access by concurrent users, ensuring that only a single user can write to the database at a time. In addition, a unique timestamp system records changes by each successive user. The system writes a group of related database updates as a unit, first to the transaction log, and then to the database, allowing data to be regenerated automatically in case of system error.

06) How does Birdstep RDM Embedded's choice of database models help developers model data?
The database allows developers to combine the strengths of two proven database models: relational and pointer-based. Developers can utilize the easy-to-use relational database model, or the network database model with the advantages of greater data integrity, higher performance, and reduced storage requirements. Birdstep RDM Embedded also allows developers to combine both models in a single application, so the benefits of both can be utilized to optimize applications.

07) How does Birdstep RDM Embedded help developers determine the duration of a database operation?
By utilizing the network database model Birdstep RDM Embedded is able to provide deterministic results. The database also allows page and cache size to be set by the developer.

08) How does Birdstep RDM Embedded use sophisticated caching to minimize disk I/O?
The database enables developers to gain greater control over the frequency of disk I/O by setting page and cache sizes. Excessive disk I/O is one cause of poor database performance. Birdstep RDM Embedded has a uniquely flexible database design capability allows developers to have fine control of disk I/O.

09) Why doesn't RDM Embedded support all of the SQL API?
Embedded SQL was originally designed from the ground up to run in restricted environments. In these environments, excess code in a database engine takes away from valuable space needed by applications. Our selection of ODBC API functions and SQL language was based on what was essential for programming embedded applications. Even in larger environments, a complete SQL is not desirable. Embedded databases are typically controlled by a single application where the concept of users with various levels of access rights on views of the database is irrelevant. By omitting views and access rights functionality, Embedded SQL is optimized for the embedded deployment.

10) Can I use mirroring to create fault tolerant applications?
Yes, the RDM Embedded Mirroring System (REMS) provides an integrated, engine-level solution for mirroring main database modifications to a single mirror copy of that database. REMS assists developers in creating Fault Tolerant applications; however the design does not attempt to make fault tolerance an engine feature. It is the developer's responsibility to use the data redundancy features provided by the engine to implement the specific level of fault tolerance required within their application suite. If the main database becomes unavailable, mirroring capabilities allow a refresh of the main database, or allow the application to begin accessing the mirror.

11) Can I use my existing application with RDM Embedded without changing the dt_ API?
Yes, the RDM Embedded API is slightly different than the two API's provided by RDM Embedded 5.0. The native RDM Embedded API always includes a task parameter, and always uses the "d_" prefix. This release provides optional translations from the previous "dt_" API to the new form of the RDM Embedded API. Programmers may choose to leave existing applications unchanged by using one of the provided translations, or they may change their source to the new API. To utilize the translation, preprocessor constants must be defined, either on the command line or in application source code prior to the RDM Embedded headers.

12) Why did you add XML capability?
Customers use RDM Embedded in application specific software packages, which need to be integrated into other systems. Ease of integration requires the data between our customer's system(s) and their customer's system(s) to be easily exchanged. Because XML is a standard language and growing in market acceptance, Birdstep chose to add the XML I/E layer to allow for easy data interchange between XML aware systems.

13) Why did you choose and Import/Export layer?
By implementing an Import/Export layer there is no change to the standard operation of the dbms (database management system) - the layer is an additional set of API and does not require customers to learn a whole new database engine architecture. The I/E layer allows RDM Embedded to maintain its industry recognized run-time performance. The I/E layer does not impact RDM Embedded upgrades because all of the traditional database connectivity is still supported (i.e. SQL, Native d_, and JNI).

14) What can I do with the XML I/E layer?
The XML Import/Export layer is a set of API functions and utilities that can be used by the application in run-time or administrative mode. RDM Embedded XML can consume a well-formed document with or without DTDs or XML Schema. Similarly, RDM Embedded can export an XML document with or without DTDs or XML Schema as specified by the developer.

15) How does this affect my upgrade?
For customers who do not plan to use the XML interface, there is no change to the database and application upgrade process from prior versions of RDM Embedded to RDM Embedded 7.1.

16) Is there a performance penalty using the XML interface?
Because we have implemented an import/export layer, there is a minor performance cost to parse and tag the data during the import and export process if your application uses this feature. Using the Native, SQL, and JNI interfaces has no change in performance.