Expanding Database Plugin Options

[ajhalls]

So, this may be a longshot, but I figure you might be the guy to answer it. A few years ago, I wrote a program that lets me identify the structure of fixed length, fixed width database layouts: https://www.youtube.com/watch?v=OMeghA82kSk

I was working today on a Sybase SQL Anywhere file, which is a single DB file similar to SQLite, and I started looking at the binary structure and started wishing I could use SQLiteStudio to open the file. I noticed you had a couple extra supported databases, and was interested in learning how possible it might be to develop a plugin that allows your app to open additional binary database files.

With what I already built, I can open and parse the old C-Tree database files, using the C# LINQ to query the data. It supports multiple datatypes to resolve integers, dates, and so on. While that system uses a new file for each table, there are so many other systems like an Access database, INNODB, and others that are a single file.

I love how with SQLite, I don't need a server running, and I realized that with your application, it may be possible to open other binary files in the same way, if the definitions were available.

Anyway, I would love to collaborate, if you are interested. On a regular basis I am interacting with C-Tree, Sybase, Pervasive, MySQL, MSSQL, and working on others to expand what I can do.

[pawelsalawa]

The database plugins in SQLiteStudio are designed specifically for different variations of SQLite. It won't be suitable for other kind of data storages (such as Sybase, Pervasive, nor MySQL). Database plugins in SQLiteStudio expect the plugin to provide interface that "talks" and "understands" C API and SQL specific to SQLite databases.

More possible solution would be to write an import and/or export plugins (also available in SQLiteStudio), which are able to translate from/to desired storage format.

[Stephen-Leibowitz]

Perhaps using ODBC would help: SQLite ODBC Driver

If ajhalls just wants to query the data using SQLiteStudio, then using CSV as an exchange format might be acceptable. See Import task automation.

[pawelsalawa]

It's not just about accessing databases, but understanding their SQL syntax (each database has its own variation) and supporting all the special features (which also is individual to each database type).

That's why the only feasible solution would be to create Import plugin, which does not have to support all the perks of specific database, but deals only with the data in tables.