Результаты поиска

Да, я знаю. Существование запущенной копии SQL Server 6.5 в 2008 году абсурдно.

Таким образом, каков наилучший способ перехода с 6.5 на 2005 ? Есть ли прямой путь? Большая часть документации, которую я нашел, касается обновления 6.5 до 7 .

Должен ли я забыть о собственных утилитах обновления SQL Server , сценарий из всех объектов и данных, и попытаться воссоздать с нуля?

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

Обновление. Вот как я закончил это делать:

• Создайте резервную копию базы данных, о которой идет речь, и мастер на 6.5 .
• Выполните SQL Server 2000 's instcat.sql против 6.5' S Master. Это позволяет поставщику SQL Server 2000 ' s OLEDB подключиться к 6.5 .
• Используйте SQL Server 2000 ' s standalone "Import and Export Data" для создания пакета DTS, используя OLEDB для подключения к 6.5. Это успешно скопировало все таблицы 6.5 в новую базу данных 2005 (также используя OLEDB ).
• Используйте 6.5 ' S Enterprise Manager, чтобы записать все индексы и триггеры базы данных в A .sql файл.
• Исполни это .Файл sql для новой копии базы данных в среде Management Studio 2005 года.
• Используйте 6.5's Enterprise Manager для создания сценариев всех хранимых процедур.
• Выполните этот файл .sql в базе данных 2005 . У нескольких десятков sprocs были проблемы, делающие их несовместимыми с 2005 . В основном non-ANSI joins и quoted identifier issues .
• Исправлены все эти ошибки и повторно выполнен файл .sql .
• Воссоздал логины 6.5 в 2005 и дал им соответствующие разрешения.

Было немного промывки/повтора при исправлении хранимых процедур (их было сотни, чтобы исправить), но обновление прошло отлично в противном случае.

Возможность использовать Management Studio вместо Query Analyzer и Enterprise Manager 6.5 -это такая удивительная разница. Несколько запросов отчетов, которые заняли 20-30 секунду на 6.5 database , теперь выполняются за 1-2 секунды, без каких-либо изменений, новых индексов или чего-либо еще. Я не ожидал такого немедленного улучшения.

Каковы наилучшие методы отслеживания и / или автоматизации изменений схемы DB? Наша команда использует Subversion для управления версиями, и мы смогли автоматизировать некоторые из наших задач таким образом (перемещение сборок на промежуточный сервер, развертывание тестируемого кода на рабочий сервер), но мы все еще делаем обновления базы данных вручную. Я хотел бы найти или создать решение, которое позволит нам эффективно работать на разных серверах с различными средами, продолжая использовать Subversion в качестве бэкенда, через который код и обновления DB передаются на различные серверы.

Многие популярные программные пакеты включают в себя сценарии автоматического обновления, которые обнаруживают версию DB и применяют необходимые изменения. Является ли это лучшим способом сделать это даже в более крупном масштабе (через несколько проектов, а иногда и через несколько сред и языков)? Если да, то есть ли какой-либо существующий код, который упрощает этот процесс, или лучше всего просто запустить наше собственное решение? Кто-нибудь реализовывал что-то подобное раньше и интегрировал его в Subversion post-commit hooks, или это плохая идея?

Хотя решение, поддерживающее несколько платформ, было бы предпочтительнее, мы определенно должны поддерживать стек Linux/Apache/MySQL/PHP, поскольку большая часть нашей работы находится на этой платформе.

Есть ли способ легко конвертировать отчеты Crystal Reports в формат Reporting Services RDL? У нас есть довольно много отчетов, которые скоро будут нуждаться в преобразовании.

Я знаю о ручном процессе (который в основном восстанавливает все ваши отчеты с нуля в SSRS), но мои поиски указали на несколько возможностей с автоматическим преобразованием "acceleration" с несколькими консалтинговыми фирмами. (Как описано далее .... - ссылка сломана).

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

В настоящее время мы используем MySQL для продукта, который мы создаем, и стремимся перейти на PostgreSQL как можно скорее, в первую очередь по причинам лицензирования.

Кто-нибудь еще сделал такой шаг? Наша база данных-это жизненная сила приложения и в конечном итоге будет хранить TBs данных, поэтому я очень хочу услышать об опыте работы improvements/losses, основных препятствий в преобразовании SQL и хранимых процедурах и т. д.

Edit: просто чтобы разъяснить тем, кто спрашивал, почему нам не нравится лицензирование MySQL. Мы разрабатываем коммерческий продукт, который (в настоящее время) зависит от MySQL в качестве бэк-энда базы данных. В их лицензии говорится, что мы должны платить им процент от нашей прейскурантной цены за установку, а не фиксированную плату. Как стартап, это менее чем привлекательно.

Кто-нибудь знает быстрый и простой способ переноса базы данных SQLite3 в MySQL?