2 UA3GDW:
А чтобы просто так нормально отработал merge для 2-х баз данных, где нет автоинкремента, не знаю. Тут надо писать уже сравнение всех полей или делать нормальный дамп по каждой базе. Но не через attach. Он всегда работает с ошибками.
А вот нет такого кода на SQL сразу... :( Сама задачка непростая. Так как тебе надо в запрос передавать всякий раз номер ROW_NUM. И потом с ним работать. А что будет, если такой же номер есть в другой базе, которую ты хочешь объединить? Будут грабли. Для этого и придумали механизм сравнения данных через Diffgrams. По-другому, даже не знаю, как решить такое.
И зачем тебе такой мазохизм? Делай ты на нормальном автоинкременте с индексом. В 100 раз проще. И думать не надо. И объединять записи и сливать две/три или более баз в одну.
PS. Крутани вот здесь, там вроде исходники есть. Кое-что напильником придется, но вроде чел решал твою задачку:
https://ongardie.net/blog/sqlite-in-git/
Для уникального ID, который ты знаешь всегда, код на SQL будет такой:
SQL = "INSERT INTO [DB_NAME] SELECT * FROM TOMERGE.[DB_NAME] WHERE [YOUR_UNIQUE_ID] NOT IN (SELECT [YOUR_UNIQUE_ID] FROM DB_NAME)
где в коде на шарпе сначала:
string SQL = "ATTACH '" + fileLoc + "' AS TOMERGE";
Но сам аттач работает криво. Но как ты будешь передавать свой ROW_NUM, не знаю. Он у тебя не уникальный.
PS. Без нормальной хранимой процедуры с параметрами или двух/трех вложенных селектов не обойтись будет.
Последний раз редактировалось RX1AL; 26.06.2015 в 00:22.
Роман, функция конкатенации CONCAT в SQL - немного не то, что тебе нужно. CONCAT преобразует типы аргументов к строковому типу данных и все. Она не делает проверку на твой ROW_NUM. Она просто добавляет, в твоем примере, к строке "Проект" цифру и все. То есть по сути: "Проект1", "Проект2" и т.д. Не более. Тебе же нужно совсем другое.
PS. Ладно, на сегодня все. Завтра выставка и дня 3 меня не будет.
Тебе же нужен именно MERGE и COMPARE, но с параметрами.
Тут дело не в последнем номере, его то получить не проблема. Проблема в другом. У него есть, скажем две базы данных. В одной из них есть записи с номерами 2, 4, 5, 6, 8, 10, 15 (ROW_NUM), а в другой могут быть 3, 4, 5, 7, 8, 11, 14, 15, 17. И надо их объединить. Простой UNION здесь не прокатит, так как надо сравнивать и остальные поля на их правильность. Одного толку от знания ROW_NUM не будет. И что делать с теми ROW_NUM, которые одинаковы: удалять, не включать в селект или апдейтить? Решений несколько. Не совсем понятен подход к решению задачи. Зачем так сложно, когда можно на основе уникального автоинкрементного поля все сделать быстрее и надежнее? Пока непонятно.
Последний раз редактировалось RZ1ZR; 26.06.2015 в 18:28.
Всё равно до конца не понял проблему.
Вытащить можно только по какому-то уникальному полю...но если таблицы уже созданы неправильно, то бороться придётся с тем, что есть....т.е искать это поле и тогда нет проблем.
Из моей практики, когда надо было сравнить свои таблицы и чужие(неправильные) применил
DENSE_RANK() OVER (PARTITION BY t.intInvBID order by t.intto,t.intTransac tionID) as Num
чтобы сделать этот самый уникальные номер.
но это T-SQL.
В Microsoft SQL 2012 много добавили всяких аналитических фукций для такого рода задач.
Разумеется, только уникальному. Я об этом, как раз Роману и написал. Но у него поле Int64 (ROW_NUM) и не уникальное. Честно говоря, не понимаю, зачем такой дизайн (мазохизм?) нужен. Может автор нам пояснит. И если есть возможность (пока база данных с таблицами не разрослась), то исправить что-то. Иначе без уникального поля сделать что-то будет просто изврат, и сорри, полный гемор...
Да, функций то добавлено много в 2012/2014 SQL Server. Но Роман использует другую базу - SQLite, а там всех "плюшек" полезных нет. Я ему посоветовал сделать на основе Diffgrams, он пока не хочет. Хотя такой путь пока единственный, когда нет уникального поля. Так как Diffgrams сравнивает содержимое каждого поля, а также по внутренним таблицам (дампу) анализирует, что и когда было изменено.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)