Разъяснение причин и причин этого вопроса: Эта ситуация может лучше проиллюстрировать, почему вам может потребоваться сделать то, что запрашивается:
Синхронизировать данные сервера со встроенной базой данных (Sqlite).Передайте изменения с клиента на сервер, а затем загрузите изменения на клиент (upsert).
В этом случае CommandBuilder необходимо включить целочисленный первичный ключ из исходной таблицы SQL Server, который представляет собой BIGINT IDENTITY, и INT AUTOINCREMENTв Sqlite (в SQLite3 столбцы INTEGER ROWID имеют значение INT64, поэтому для соответствия SQL Server должен быть BIGINT).
Теперь в Sqlite вы можете указать столбец PK при вставке, и он его принимает; вам не нужно ничего делать, как SET IDENTITY_INSERT ON.Так что вам действительно нужен столбец PK в команде вставки.
Вы можете смешать что-то, используя код выше, но было бы намного проще, если бы CommandBuilder каким-то образом включил первичный ключ.
В этой теме говорится о ручном взломе свойства InsertCommand.CommandText, но, на мой взгляд, оно слишком взломанное.
Возможно, существует проблема с вызовом da.Обновить().Более низкая запись в этой теме указывает, что ADO может стереть любое добавление параметров вручную, и предлагает решение путем копирования адаптера данных перед вызовом Update ().Другой поток рассказывает историю о том, кто кого-то столкнулся с этой проблемой (хотя в этом потоке нет разрешения).
Итак, после долгих размышлений я выяснил это о Sqlite: если таблица использует AUTOINCREMENT для основногоключ, вместо разрешения поведения по умолчанию для целочисленного первичного ключа (автоматически делает плюс один, когда столбец первичного ключа не указан при вставке), тогда вы не можете вставить свое собственное значение для первичного ключа.
Мое окончательное решение, потому что у меня не хватило времени, было сделать то, что было описано здесь , то есть я удалил AUTOINCREMENT из локальной базы данных Sqlite, взломал InsertCommand.CommandText и вручную добавилстолбец первичного ключа как обычный параметр (без добавления его в качестве первичного ключа):
SQLiteCommandBuilder commandBuilder = new SQLiteCommandBuilder();
commandBuilder.DataAdapter = daLocal;
SQLiteCommand insertCommand = commandBuilder.GetInsertCommand(true);
insertCommand.CommandText = insertCommand.CommandText.Replace("] (", "] ([id], ");
insertCommand.CommandText = insertCommand.CommandText.Replace("VALUES (", "VALUES (@id, ");
SQLiteParameter pkParam = new SQLiteParameter("id", DbType.Int64, "id");
insertCommand.Parameters.Add(pkParam);
daLocal.InsertCommand = insertCommand;
Это дало желаемый эффект вставки значений первичного ключа из исходной таблицы SQL Server в локальную таблицу Sqlite.
В конце концов мне не удалось найти свойство объекта DataTable или объекта SQLiteDataAdapter, которым я мог бы манипулировать, что могло бы привести к тому, что либо SqliteCommandBuider, созданный явно, либо создатель SQLiteDataAdapter, создали столбец id и параметр для SQLiteDataAdapter.InsertCommand.
Удачи.