Миграция с SQL2000 на SQL2017 - изменения синтаксиса

---

Всем привет,

Я провел некоторые поиски, но не нашел ничего особенного, поэтому подумал, что один из вас, умных людей, мог бы сделать это сам и, возможно, сделать некоторые заметки..

У нас есть несколько древних приложений VB legacy, работающих на SQL2000, и мы намерены перейти на SQL2017.

Теперь я знаю, что уровень совместимости остановит нас в наших треках, однако весь код создания таблиц и определения полей, а также отношения и индексы кодируются внутри самого приложения, то есть если я хочу создать новую базу данных для нашего клиента, у нас есть набор шаблонов создания таблиц, создания индексов и отношений и т. д... поэтому я с удовольствием экспортирую данные из 2000 года в Unicode CSV с помощью кода.

Затем запустите код create database .net в SQL2016, чтобы наши таблицы, индексы и отношения были воссозданы с пустым содержимым, а затем импортируйте каждую таблицу обратно в 2017 год, очевидно, используя новые имена типов данных, где они изменились.

По крайней мере, это то, что я имею в виду - моя проблема заключается в различиях между синтаксисом команд SQL - мы не используем процедуры или что-то, что связано с SQL Server, " все " работает с VB6 или VB.NET код через ADODB или OLEDB, поэтому единственное, что я ищу (если я нахожусь на правильном пути), - это изменения в самом нашем SQL-коде при выполнении выбора по нашим собственным таблицам, например
Выберите топ-10 * из mytable
вероятно, теперь SELECT * FROM MyTable LIMIT 10 OFFSET 0

но есть ли другие изменения - такие как правые соединения, приведение, преобразование, случай когда.

Мы также не используем BLOB - объекты, и я знаю, что некоторые из наших типов данных будут отличаться, ntext, по - моему, теперь nvarchar(max), нам не нужно ставить N' для вставки или обновления текстовых данных поля unicode-есть ли другие-есть ли шпаргалка, которую кто-то знает о перечислении всех синтаксических различий. Я знаю, что, вероятно, не смогу подключиться к sql server 2017 через ADO, но мне нужно использовать ODBC, который медленнее подключается, но, по крайней мере, он будет продолжать работать до тех пор, пока мы не будем полностью совместимы с OLEDB.

Есть какие-нибудь мысли по этому поводу или предложения, которые я мог бы пропустить?

Что я уже пробовал:

еще не пробовал! просто пытаюсь немного спланировать

---