Good evening

This is the sequel to the previous discussions on sqlite2dbase conversion

• https://www.linuxquestions.org/quest...on-4175592944/
• https://www.linuxquestions.org/quest...at-4175593375/

Background: I am converting SQLite-files to dBase with a ruby-program that I am developing. As I am unable to determine in the original database-tables those fields which contain calendar-dates or timestamps, I need this indication from the user of the converter.

Problem: As the database may consist of several tables, and different fields may have to be mapped in each table, the user's input on datetime-values has to be 2-dimensional. Also, I cannot foresee the kind of data that will be converted or how many fields of this type should be expected.

Question: I see currently three different possibilities to obtain the information:

1. program-arguments in the format --date table_name:"list of fields" and --time table_name:"list of fields"
2. restrict the conversion to only 1 table at a time and name the table-name in a single, new parameter, like --tname [table] --date "field1 field2"
3. introduce a program-option “date_time=text_file.txt”. The text-file contains the list of datetime fields for each table, like in

   table_1:

   date: field1, field2

   table_2:

   date: field4
   time: field7

For the time, I like the first option most, as it is easier to implement. Would you see other constraints or reasons why one alternative should be preferred?

of course 1, command line arguments with ruby are fun
https://www.sitepoint.com/ruby-comma...nterface-gems/

but it depends also on how you are planning to distribute this. does it have to be on many machines and everything shall work as easy as possible, than distribute the program with a default config. so you might want a config file in this case. And of course the command line arguments should be able to overwrite the config file values/settings.

2 members found this post helpful.

As a side note to start, I finally had a look at the cookies file you referred to and now understand why this is an issue My personal sqlite databases all have well defined (ie. datetime) fields
so I was struggling to understand the ambiguity

I agree that command line may initially seem easiest but for large databases this couple be a lesson in futility to have to type out every place where there are date/time fields.
So for small databases I see this as a positive but for larger ones I would use a file and yaml comes to mind as it integrates nicely with ruby (and others of course).

2 members found this post helpful.

Personally, I'd go the config file route, but as a4z said, it depends on how you're going to distribute this. If it's for your own use, do whatever you'd like, but if it's for others, and it has a lot of config options, I'd go config file. You can put comments in the config file, describing what each does, the various options for each bit, etc., so the end-user can easily pop it open with an editor, see what's up, and make changes to suit them.

Yes, there are man pages or "--help" options, but I personally find it irritating to have the --help options run off the screen where I can't see the syntax without scrolling back and forth. Or having to open another window side-by-side, just to make sure I get the syntax right.

Just my $0.02 worth...you did ask for opinions.

1 members found this post helpful.

Whereas I would write a simple program that converts one table at a time.

A (required) command-line parameter would reference a configuration file that is appropriate to that conversion. You would create a file for each table, and you'd create a separate script that invokes your program multiple times, once for each table.

Not only is your program now much simpler to write, but also it can readily be invoked for "just one table" if (as is likely to be the case ...) you discover that you "almost" got what you wanted, but you now need to tweak just one or two tables.

1 members found this post helpful.

Maybe stay in sqlite and create a temp table with the appropriate fields structure then copy and convert table into the temp table?

I am sorry, but do not understand this proposition. As there is a chance for a misunderstanding, though, I'd like to insist on the fact that the original SQLite-tables must, each one, entirely be transformed to dBase. In your proposition, though my English fails me, I sense something like a “filter”. But that is not, what I need.

All responses are helpful, in this thread, be it, to confirm my own ideas... The possibility to mirror command line arguments in a configuration file, where the syntax is more or less kept identical, has its charms.

Thanks for pointing it out.
I have no idea, what the original databases will look like. My decisions in this case and others will also determine, to some extend, the uses and the users of my utility. That is why the current topic is somewhat crucial (and trivial at the same time).

As you have opened the can already, you may have seen the logging-configuration and the translations-file. Only the latter is in yaml-format *). I fear that the simplicity is lost, if I do not take care to choose the right syntax and structure. Yaml is a gift. But it may impose itself as a construction site on its own or what the French call “usine à gaz” (Gas-factory? - I only understand the term since I have seen the first methaniser on a farm nearby: “Where is the farm, actually?”).

*) The yaml of the logging-configuration had been replaced by an eval(Hash{} ) syntax, already years ago and I forgot. This is even simpler as the original yaml. A similar approach could be used for the table:field_list argument, I guess.

If I examine my own old code more often, I could learn something new every day... is that Alzheimer?

This is where I agree completely. I do consider the --help option too restrictive in that I cannot express freely. Also, my English is limited and my vocabulary imposes lengthy and rather verbose explications.

In deed.

I would like to comment more, but have to leave now. I am picking apples at a neighbour and friend's site or help him do it... whatever.

1 members found this post helpful.

You write a sqlite table to dBase converter, in my sense it is not a converter job to fix the fields structure while converting the table. But it's just in my view (edit: of course the converter still has error checking responsibility)

I know I would fix the tables in sqlite itself before converting them, maybe using a fixer script.

Why not both?

A parameter file with rows having tablename, fieldname and type

If no args, then use the parameter file
else
[-t<tablename>] [-f<fieldname>] [y<type>]

OK
https://www.tutorialspoint.com/sqlit...data_types.htm
https://www.sqlite.org/lang_datefunc.html

1 members found this post helpful.

If your target is dBase files, then you should be able to find database-driver software which directly speaks this format, and some kind of "Data Pump" program that knows how to move data from one driver to another.

Note that there are several subtly-different flavors of "dBase-like files," especially when it comes to security schemes and indexes. (I know this first-hand from having written a database repair utility, for Windows, which had to support all of them. I'm not sure that I ever identified all of them ...)

I got that now.

Unfortunately, in SQLite, there do not exist Date-, Date-time-, nor Time, nor Time-stamp data-types. All is done with Integer, Real or Text. And this is the origin of my mischief. I must know, independently of the field-name nor based on a probability-algorithm (“wild guessing”), which of these fields has to be converted, as dBase uses only Text for the dates. The only dBase format that I can write, also needs a specific format-string.

... and there are two different epochs, which makes it difficult to “recognize” those number-values as dates or time-stamps.

That is, if I understood any of the docs correctly.

The question “Why not both” can be considered synonymous to the title I chose for the topic.
I imagine a user who uses my utility. Why does she/he do it? What kind of database will be converted? How often does this happen and will this concern a considerable number of different databases?

A user who works with 1 database and occasionally needs a dBase version identifies best with the original target audience. My idea is inspired by an Office software which is incompatible with anything but dBase. Folks who suffer from the absence of a decent GUI to define and manage dBase files, oftentimes have an address-database to maintain. Maybe they use dBase to organize their music collection... what else... I am at a loss. But I read the complaints. These guys would live well with a configuration file.

Then, let us assume that the existence of a converter gets users of modern databases interested in dBase... (I've seen dumber cartoons).
In this scenario, the use-cases may be completely different and a variable parameter-list would maybe more often correspond to the demands.

This evening, I am in favor of a configuration file, simply because I consider the second scenario unlikely.