forked from shuebener/SQLiteCompare
-
Notifications
You must be signed in to change notification settings - Fork 0
/
readme.txt
49 lines (27 loc) · 2.17 KB
/
readme.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
SQLite Compare is a database comparison and merge utility for Windows 7/8/10
SQLite Compare V3.0
---------------------
- Fork of SQLite-Compare-Utility (http://www.codeproject.com/Articles/220018/SQLite-Compare-Utility).
- Using .NET 4.6.
- Using NuGet library packages.
SQLite Compare V2.5
---------------------
Features:
- Blazing fast in-memory schema comparisons.
- Optimized data comparison engine capable of
comparing even huge tables with millions of rows.
- WinMerge-like schema difference view and operations.
- SQL change script generation - useful for supporting
database upgrades in existing installations (available
only with a commercial license).
- Intuitive data difference view for comparing individual field values.
- Open Source and Free !!
Known limitations:
1. SQLite Compare supports only the newer SQLite 3 file format. SQLite version 2 files are incompatible with the newer file format and are therefore not supported. If you really want to compare older SQLite file then you can convert them to the newer file format by following method outlined in http://www.sqlite.org/formatchng.html
2. Currently it is not impossible to rename a column in the schema diff view. This is a limitation caused by the inability to determine if a new column was added or an existing column was renamed. The workaround is to do such renames in another SQL management tool and than run the comparison if necessary.
3. BLOB field comparisons tend to take more time to execute, especially when
big BLOBs are involved. When BLOB fields are not part of a table primary key -
they are compared using a fast algorithm that does not load the entire BLOB into memory before doing the comparison. However - when BLOB fields are part of a table primary key (should be rare but possible), there is no way to avoid loading them into main memory before doing comparisons (SQLite limitation).
4. Currently it is not possible to compare tables that have mismatching primary keys. For example - it is not possible to compare two tables where table A has a primary key composed from two integers while table B has a primary key composed of a single integer.
Enjoy :-)
Liron Levi