Innovative Concepts

Dyna DataSet

Dyna DataSet, or "dynamic dataset", is the concept of virtualizing physical dataset settings. That is, applications can treat a "Dyna DataSet" as a virtual dataset. The applications don't care the detail settings of that data set (or data source) -- they just use the result "Dyna DataSet" as a data source. If you have basic concepts of "Object Oriented Programming", you'll understand that "Dyna DataSet" makes an abstract dataset and provides applications the same interface to access different databases.

"Dyna DataSet" is useful because we need a flexible database connectivity in many cases. For example, people need to send e-mails to customers. However, different companies have different customer databases. So, an easy way to link different databases becomes important to write the e-mail sending program.

In our system, "Dyna DataSet" includes three parts:

  1. A database connection wizard which helps users connecting to target database/table. Also, users can use this wizard to view/edit the data they are going to use.
  2. A way to save the settings. In other words, a file format which can store various database connection settings.
  3. A way to load the saved connection settings. Also, the final applicatin program can use the saved DB connection settings to access the data.

A "Dyna DataSet" should be flexible/universal because you can't predict what kind of database people want to use. However, an omnicompetent database connectivity is unnecessary/impossible because we need to put all possible DB drivers into one software package. Our strategy is to:

@Dyna Form

The concept of "Dyna Form" is similar to the concept of "Dyna DataSet". A "Dyna Form" is a dynamical settings of a form layout and data source. In other words, "Dyna DataSet" defines an external data source only, "Dyna Form" defines an external "form layout plus data source".

For example, you want to send a purchase order to company A, and expect company A modifies/adds some fields, and then send it back to you. However, you can send just data to company A because it's very difficult to figure out the meaning of each data field. So, it's better if you and company A can have one program which provides a good user interface to edit/view the data. Sure, the editing program should be universal to handle most cases, then we can use just one program + many layout setting files instead of writing many different programs.

"Dyna Form" is the solution to the above requirements. You can treat "Dyna Form" as a resource file or layout setting file which defines the data and user interface. Currently, "Inter DB Editor" can only show a dyna form, you need to use "Delphi" or "BCB Builder" to design the form (save "*.dfm" in binary format). We are planning to write our own form designer to help people building their "Dyna Form". This tool will be included in our "eForm project".

What is DSS?

DSS (Data Source Stream) is a format designed for data exchange and backup, and it's ideal for relational databases -- the most popular database architecture. As you know, a relational database consists of one or many data tables (physical datasets), and we use queries/stored procedures to extract useful information form tables. A "dataset" is a logical record set whose data comes from a table or a query. A good data exchange engine should be able to extract/restore data from/to relational databases easily  because most IT systems are using databases. DSS is good for  data exchange and backup because it is designed for it. We don't think there is a universal solution which may solve any problem! The main features of DSS are:

  1. DSS file contains all the abstract information of the datasets it contains. So, we may rebuild the original datasets by the DSS file independently.
  2. To be more efficient, DSS is in binary format. Thanks to its flexible design, there is an XML version of DSS. You can use its XML form if you feel uncomfortable to use binary format.
  3. The design of DSS format makes DSS viewer easy to be implemented. The DSS viewer doesn't need to parse the whole file when we open it. This makes DSS viewer internet ready and consumes little memory.
  4. One DSS file can hold many (related or unrelated) tables (queries/logical datasets), and stores their master/detail relations in that DSS file.

Why DSS?

  1. It's compact/flexible/ and easy to be understood.
  2. It supports multiple dataset with master/detail relation in one file. This is very important for data exchange or DB backup. Current existing DB packing formats consider one dataset only.
  3. There is an one-to-one mapping between DSS and DataSets. Any database can be converted to DSS, and vise versa. In addition, DSS has an XML form to make it available for general  XML parsers. However, XML is an abstract meta language with high flexibility. You can't convert any XML into databases. Besides, you need to set some standards before you convert databases into XML because there exists many conversion ways! Let's say, XML is an language while DSS is a format! XML is very flexible and it can be anything. DSS is flexible in only a specific field (database). It would be very useful if your application is just located in this field.
  4. Many related application package are developed already. Users can have good starting point when they choose to use this format.
  5. Many related components (TDSSDataSet, TTCPDSSDataSet, ...) are developed. Developers can use these component to access DSS file directly.
  6. DSS supports Windows and Linux now.
  7. A DSS file can be very huge (for example, 2GB), however, can be opened very quickly. Because DSS format eliminates the need of parsing the whole file in advance. You can browse a DSS file via slow internet connection easily.

The comparisons between DSS and XML

It is a data representation language rather than a data format and is too flexible for a specific application. It is not a data representation language but a flexible format. For example, you'll use JPEG files as the standard of photo image files, but you won't use "XML" because XML does not help the image compression/decompression and representation. If you use XML, it'll be an "XML" version of JPEG(not a new format). 
It's an ASCII format to make it cross-platform. The conversion of some special characters and binary data costs resources. An XML file is too large for database backup purpose. DSS is in binary format like JPEG for image. However, we do have an "XML" version "DSS" to make it easier to be processed.
Choosing XML as data exchange standard, you still need to define a standard format of XML (because XML is a language, not a format). The problem of "how to define the format" takes times. For example, the XML version of DSS is an XML file --  is it OK to people who want XML?  DSS doesn't need any standards. It assumes users are trying to exchange information from/to their database and files. The data exchange engine should be very adaptive and do most conversions.
A general purpose XML tool is still under developed. Even we have one, our problems are not solved.

 For example, I have many physical photos need to be digitalized and send to my friends. But I'm still waiting for the standard of "XML" to appear to solve my problem. Isn't it ridiculous?

What I should do is to buy a scanner, scan my photos into JPG/PNG/GIF/BMP  and mail/ftp these files to my friend! Why should I wait for XML standard? XML is a flexible data representation language, but not the solution to everything!

DSS is designed for the existing IT systems. Many utilities/components are developed for this format. Companies can solve their problems immediately. @