Dynamic typing
A SQLite type declaration is an affinity hint, not a
constraint, so a column declared INTEGER can hold
text in real rows. The conversion follows the declaration, and
the type-mapping review lists every column with the SQL Server
type it will get, so you retype the ones your data has outgrown
before the run.
Generated keys
Maps SQLite INTEGER PRIMARY KEY /
AUTOINCREMENT (tied to ROWID) to SQL
Server IDENTITY on the PK column, and reseeds
with DBCC CHECKIDENT above the loaded maximum
key value - so the application's next insert does not
collide.
Dates and booleans
SQLite has no date or boolean type: applications store dates
as ISO-8601 text and booleans as 0/1 integers. Those columns
arrive as the type they were declared with, so pick
datetime2 or bit for them in the
type-mapping review.
GUID values and Unicode
Validates SQLite text GUIDs and maps them to SQL Server
uniqueidentifier on the target, and creates
string columns as nvarchar so Unicode
round-trips safely without the source needing a
VARCHAR(n) CHARACTER SET hint.
Triggers, CHECK constraints, and procedural code - out of scope
DBConvert's migration covers tables with their fields, types
and indexes, and foreign keys between them. SQLite triggers,
CHECK constraints and WITHOUT ROWID
table specifics stay in the source and are recreated manually in
T-SQL where the equivalent feature exists - CHECK
constraints port one-for-one when the expression is portable. Application code written around SQLite locking, pragmas, and local-file paths also needs review before the application points at SQL Server.
