Linux packages should include a man page.

pgdbsc does not use a transaction on the source database when importing data. This can result in transactionally inconsistent data if the source database is in use.

Npgsql on Linux does not support integrated security. pgdbsc should show a nice error message if a username is not specified when running on non-Windows systems.

Wildcards: MySchema.foo*

Negations: -BadTable

Custom SELECTs: MyTable : SELECT * FROM MyTable
WHERE Import = 1

Source database port is 0 when not specified. It should be null instead.

I don't have a Mac to test on but fpm supports creating Mac packages. Maybe I can find someone to test for me.

Oracle support for running scripts, not importing yet.

Write an automated integration test suite for all 3 flavors.

Add build target for building a Red Hat/CentOS/Fedora/etc .rpm package for mydbsc.

Add build target for building a Debian .deb package for mydbsc.

Scripts could do things that affect connection state. For example, using SET in SQL Server to set options such as XACT_ABORT, QUOTED_IDENTIFIER, etc. Use a separate connection for each script to ensure each script gets a fresh environment.

Provide packages that follow these guidelines so users can just run

pgdbsc -h

instead of

mono ~/pgdbsc/pgdbsc.exe -h

Add build target for building a Debian .deb package for pgdbsc.

It would be more in line with user expectations to only leave tables that are not being imported alone instead of clearing them.

An error message looks like this right now:

Error: ERROR: 42601: syntax error at or near ";"

which could give more diagnostic information.

Can anything be done to speed up the Windows installers?

Make an installer for mydbsc.

Error: No operation specified. pgdbsc.exe -h for help.

On Linux with the (in progress) package, dbsc is invoked with a wrapper script which is named pgdbsc, mydbsc, or mongodbsc. Modify the above message to not include the ".exe".

"Setting this to true indicates that the provider expects user variables in the SQL."

Migration scripts are likely to wan to use variables.

It is hard to remember which is correct.

Add build target for building a Red Hat/CentOS/Fedora/etc .rpm package for pgdbsc.

Write a nice readme and documentation so people know how to use the darn thing.

MongoDB may be schemaless but you still need to add indexes, add static data, migrate data from one "schema" to another, etc.

Scripts would be js instead of sql.

DBSC goes web scale!

PostgreSQL 9.3 introduced a FREEZE option to the COPY command. COPY FREEZE does not speed up the import itself but makes operations after the import faster.

It does violate visibility rules by making the data visible to other transactions before the import transaction is committed, but that's not an issue for imports as you would not be importing data into a database in use.

A timestamp of the last time a database update was applied might be useful. Only update it when a script is actually run.

Importing with mydbsc uses the mysqldump and mysql command line programs, passing username and password on the command line. mydbsc displays output from those programs, which includes a warning about passing password on the command line.

Is there a way to avoid passing password on the command line?

DatabaseName.some_comment.1234.sql causes the scripts to not be ordered when sorting alphabetically in a file explorer.

Change to DatabaseName.1234.some_comment.sql.

Something like

pgdbsc revision -targetDbServer localhost

which would output just the revision number.

Check for the presense of mysqldump and mysql before doing an operation that would import in mydbsc and display a friendly error if they are not.

Don't show notices that PostgreSQL displays when creating implicit indices on primary keys or creating implicit sequences for serial columns. They look like:

NOTICE: CREATE TABLE will create implicit sequence "mal_anime_synonym_mal_anime_
synonym_id_seq" for serial column "mal_anime_synonym.mal_anime_synonym_id"
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "mal_anime_synonym
_pkey" for table "mal_anime_synonym"

They got bumped down to DEBUG1 level instead of NOTICE in PostgreSQL 9.3 (http://www.postgresql.org/docs/devel/static/release-9-3.html) but it will be quite some time before most people will be running 9.3.

Doing an import of a SQL Server database that is in use can result in consistency issues or failures when re-enabling foreign keys after the import.

To allow for consistent imports of databases that are in use, check if snapshot isolation (http://msdn.microsoft.com/en-us/library/ms345124%28v=sql.90%29.aspx) is enabled on the source database:

SELECT snapshot_isolation_state_desc from sys.databases
where name='MyDatabase'

If snapshot isolation is enabled, wrap the entire import operation in a snapshot transaction on the source database.

Also document this behavior.

sp_msforeachtable is undocumented and is subject to quirks such as QUOTED_IDENTIFIER being OFF for SQL executed by it.

Trying to do anything other than the CREATE DATABASE statement in a create DB template in pgdbsc gives the error

Error: ERROR: 25001: CREATE DATABASE cannot be executed from a function or multi-command string

You would not be able to do much else interesting like setting permissions anyway because you would have to be connected to the target database instead of the "postgres" database.

Maybe have a command line parameter to specify a post-create script? Or the ability to specify an environment when creating the database and have scripts that only run for certain environments?

If you use pgdbsc to import from another DB, you need to manually run something to update the autoincrements to be what is now the highest value in the table

Add build target for building a Debian .deb package for mongodbsc.

Add build target for building a Red Hat/CentOS/Fedora/etc .rpm package for mongodbsc.

Scripts that have an extension beginning with .sql get picked up. Using an extension like .sqlx is supposed to be one way of getting dbsc to ignore a script.