mORMot Open Source

Junior/RO

Member

Registered: 2011-05-13

Posts: 210

Using mORMot to export a DBIsam table

Hi.

I have two questions:

1) Need to export data from a DBIsam table to sqlite, csv, json and sql. Can mORMot be used to export json? And Sql? Can you give me any hints?

2) What you think about using BigTable to implement a TIniFile like class?

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,660

Website

Re: Using mORMot to export a DBIsam table

To use DBIsam with mORMot, you'll need an OleDB Provider.
As far as http://www.elevatesoft.com/products states, only ElevateDB has this provider.

BigTable is not meant to replace TIniFile at all. It is meant to handle huge amount of Data.
SQLite3 is perfect for an application file format.
And you could use JSON as TIniFile replacement. mORMot has a all needed JSON process functions.

Junior/RO

Member

Registered: 2011-05-13

Posts: 210

Re: Using mORMot to export a DBIsam table

Thanks.

I think I don't need a OleDB Provider. Just want export a TDBISAMDataset. I can loop through the dataset (while not Dataset.Eof).

What I would like to know is if mORMot have classes or functions that could help me to export the fields of the TDBISAMDataset, a TDataset descendent, to the formats sqlite, json and sql.

Junior/RO

Member

Registered: 2011-05-13

Posts: 210

Re: Using mORMot to export a DBIsam table

About Bigtable replacing TIniFile, I have this idea after reading this Zed Shaw's post:

http://sheddingbikes.com/posts/1277495906.html

Where he is reasoning about the advantages of using sqlite as a config file.

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,660

Website

Re: Using mORMot to export a DBIsam table

In fact, this is the first use of SQLite, from its author point of view:

Situations Where SQLite Works Well
Application File Format

SQLite has been used with great success as the on-disk file format for desktop applications such as financial analysis tools, CAD packages, record keeping programs, and so forth. The traditional File/Open operation does an sqlite3_open() and executes a BEGIN TRANSACTION to get exclusive access to the content. File/Save does a COMMIT followed by another BEGIN TRANSACTION. The use of transactions guarantees that updates to the application file are atomic, durable, isolated, and consistent.

Temporary triggers can be added to the database to record all changes into a (temporary) undo/redo log table. These changes can then be played back when the user presses the Undo and Redo buttons. Using this technique, an unlimited depth undo/redo implementation can be written in surprisingly little code.

http://www.sqlite.org/whentouse.html

With a graphical back end, SQLite is just great as application format.

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,660

Website

Re: Using mORMot to export a DBIsam table

I think I don't need a OleDB Provider. Just want export a TDBISAMDataset. I can loop through the dataset (while not Dataset.Eof).

I spoke about OleDB since mORMot is able to link to any database engine, either with direct link (Oracle, SQlite3), either via OleDB.
See http://blog.synopse.info/post/2011/06/0 … gnosticism and http://blog.synopse.info/post/2011/08/0 … e3-limited
But it will need a full SQL engine attached to work as expected. I guess that a TDataSet won't fulfill its needs.

An easy solution could be to get the DataSet into a SQlite3 in-memory database, then use it from mORMot.
Everything is ready for it in our classes.

What I would like to know is if mORMot have classes or functions that could help me to export the fields of the TDBISAMDataset, a TDataset descendent, to the formats sqlite, json and sql.

I've just made the contrary for http://blog.synopse.info/post/2012/06/2 … t-or-SynDB - i.e. create a TDataSet from mORMot/SynDB answer, i.e. from JSON, SQLite or SQL into TDataSet.
Creating a SQLite3 in-memory database from the TDataSet is probably what you need, but it is not at all a perfect solution, since it will use memory, and add a process step.
But we wanted to get rid of any TDataSet in mORMot... By design (see the documentation about ORM)...