Приложение Доступа MS - Преобразовывает хранение данных от Доступа до SQL Server
Использование расширенного синтаксиса , Map , Array # redund и String # split
const textArea = document.getElementById("text");
const button = document.getElementById("button");
const result = document.getElementById("result");
button.addEventListener("click", function(){
const value = textArea.value.trim();
const res = getFrequency(value);
console.log(JSON.stringify([...res]));
result.innerText = `(${[...res].join("), (")})`;
})
function getFrequency(str){
return str.split("").reduce((a,c)=>a.set(c, (a.get(c) || 0) + 1), new Map());
}div {
display: flex;
background-color: lightgrey;
flex-direction: column;
}
div > div {
flex-direction: row;
}
8 ответов
Не используйте мастер увеличения от Доступа:
Во-первых, это не будет работать с SQL Server 2008.
Во-вторых, существует намного лучший инструмент для задания:
SSMA, Помощник миграции SQL Server по Доступу, который обеспечивается бесплатно Microsoft.
Это сделает много для Вас:
- переместите свои данные от Доступа до SQL Server
- автоматически свяжите таблицы назад в Доступ
- дайте Вам большую информацию о потенциальных проблемах из-за различий в этих двух базах данных
- отслеживает изменения, таким образом, можно сохранить эти два синхронизируемыми со временем, пока миграция не завершена.
Я записал запись в блоге об этом недавно.
Это - Ваша самая дешевая опция. Вы собираетесь хотеть настроить соединение ODBC для своих клиентов Доступа, указывающих на Ваш SQL Server. Можно затем использовать (я думаю), опция "Import" "связать" таблицу с SQL Server через источник ODBC. Переместите свои данные от таблиц Access до SQL Server, и у Вас есть свои данные по SQL Server в форме, которой можно управлять и создать резервную копию. Важный, запросы могут затем быть записаны на SQL Server как представления и представлены дб Доступа как связанные таблицы также.
Другие предложили увеличить Струйный бэкэнд SQL Server и связаться через ODBC. В идеальном мире приложение будет работать красиво, не будучи должен изменить что-либо.
В реальном мире Вы найдете, что некоторые Ваши объекты фронтенда, которые были спроектированы, чтобы быть эффективными и быстрыми со Струйным бэкэндом, на самом деле не работают очень хорошо с базой данных сервера. Иногда Струя не угадывает и отправляет что-то действительно неэффективное на сервер. Это конкретно случай с массовыми обновлениями записей - чтобы не к ресурсам сервера пожирателя ресурсов (хорошая вещь), Струя отправит единственный оператор UPDATE за каждой записью (который является плохой вещью для Вашего приложения, так как это очень, намного медленнее, чем единственный оператор UPDATE).
То, что необходимо сделать, оценивают все в приложении после увеличения его и где существуют проблемы производительности, переместите часть логики к серверу. Это означает, что можно создать несколько представлений серверной стороны, или можно использовать запросы к внешнему источнику данных (для вручения от целого SQL-оператора SQL Server и не разрешению Струйному беспокойству об этом), или Вы, возможно, должны создать хранимые процедуры на сервере (специально для операций обновления).
Но в целом, на самом деле довольно безопасно предположить, что большая часть из него будет хорошо работать без изменения. Это, вероятно, не будет с такой скоростью, как старое приложение Доступа/Струи, но это - то, где можно использовать SQL Profiler для выяснения то, что задержка и вещи переархитектора быть более эффективной с бэкэндом SQL Server.
Если приложение Доступа было уже эффективно разработано (например, формы никогда не связываются с полными таблицами, но вместо этого с recordsources со строгими операторами Where, возвращая только 1 или несколько записей), то это будет, вероятно, работать вполне прилично. С другой стороны, если это использует много плохих методов, замеченных в базах данных-образцах Доступа и шаблонах, Вы могли столкнуться с огромными проблемами.
Это - мое мнение, что каждое приложение Доступа/Струи должно быть разработано от начала с идеи, что когда-нибудь это будет увеличено для использования бэкэнда сервера. Это означает, что приложение Доступа/Струи на самом деле будет довольно эффективно и быстро, но также и что, когда Вы действительно увеличиваете, оно вызовет минимум боли.
У Вас есть несколько опций, мастер увеличения делает достойное (выход) задание движущейся структуры и данных от доступа до Sql. Можно затем установить связанные таблицы, таким образом, приложение 'должно' работать в значительной степени, как оно делает теперь. К сожалению, диалект Sql, используемый Доступом, отличается от SQL-сервера, поэтому если существуют какие-либо 'сырые данные sql' операторы в коде, они, возможно, должны быть изменены.
Поскольку Вы связались с таблицами, хотя все другие функции Доступа, QBE, формы и так далее должны работать как ожидалось. Это является самым простым и вероятно лучший подход.
Другой способ приблизиться к проблеме состоял бы в том, чтобы переместить данные как выше, и затем вместо того, чтобы использовать связанные таблицы, использовать ADO из доступа. Тот подход довольно знаком, если Вы привыкли к другим languages/dev средам, но это - неправильный подход. Доступ идет с загрузками созданных в материале, который делает работу с данными действительно легкой, если Вы возвращаетесь для использования ADO/Sql, Вы затем теряете многие из тех преимуществ.
Я предлагаю, запускаются на небольшой части приложения - не существенные данные, и перемещают несколько таблиц и видят, как это идет. Конечно, Вы создаете резервную копию всего сначала.
Удачи
Связанные таблицы Access хорошо работают, но я только использовал их с ODBC и другими базами данных (Firebird, MySQL, Sqlite3). Информация о первичных или внешних ключах не проходила. Были также проблемы с интерпретацией типа данных: дата в MySQL не является тем же самым как в Доступе VBA. Я предполагаю, что эти проблемы не почти как плохо при использовании SQL Server.
Важный момент: Если Вы связываете таблицы в Доступе к SQL Server, то КАЖДАЯ таблица должна иметь определенный Первичный ключ (Подрядчик? Доступ? Опыт говорит, что, вероятно, некоторые таблицы не имеют PKs). Если PK не будет определен, то формы Доступа не смогут обновить и вставить строки, представляя таблицы, эффективно только для чтения.
Вот техника, о которой я услышал, что один разработчик говорит. Это - то, если Вы действительно хотите что-то как Клиент-серверное приложение.
- Создайте .mdb/.mde frontend файлы, распределенные каждому пользователю (Вы будете видеть почему).
- Для каждой таблицы они должны выполнить CRUD, иметь локальную копию в файле в № 1.
- Формы остаются связанными с локальными таблицами.
- Напишите код VBA для обработки CRUD от локальных таблиц до базы данных SQL Server.
- Отчеты могут базироваться прочь временных таблиц, составленных от SQL Server (Не сможет составить временные таблицы в mde файле, я не думаю).
После того как Вы решаете, как Вы хотите сделать это с единственной формой, не слишком трудно применить ту же технику к остальным. Хорошая вещь о работе с формой на локальной таблице - Вы, может сохранить большую существующую функциональность как существующее приложение (Который является, почему они использовали, и продолжите использовать Доступ, я надеюсь). Просто необходимо обратиться к получению данных назад и вперед к SQL Server.
Можно продолжить иметь связанные таблицы и затем постепенно постепенно сокращать их с этой техникой как время, и производительность должна продиктовать.
Так как у каждого пользователя есть их собственный локальный файл, они могут работать над своей локальной копией данных. Только минимум, требуемый сделать их задачу, должен когда-либо копироваться локально. Пример: если бы они обновляют единственную запись, таблица только имела бы ту запись. Когда пользователь добавляет новую запись, Вы заметили бы, что поле ID для записи является Пустым, таким образом, оператор вставки необходим.
Я предполагаю локальные действия таблицы как набор данных в.NET? Я уверен в некотором роде, что это - несовершенная аналогия.
Взгляните на этот инструмент миграции Access to SQL Server. Это может быть один из немногих, если не ЕДИНСТВЕННЫЙ, настоящий инструмент одноранговой миграции или миграции с сервера на сервер, работающий как чистое веб-приложение. Он использует в основном ASP 3.0, XML, объект файловой системы, объект словаря данных, ADO, расширения ADO (ADOX), объекты сценария словаря и несколько других изящных методов и технологий Microsoft. Если у вас есть таблица доступа к источнику на одном сервере, а целевой SQL-сервер - на другом или даже на том же сервере, и вы хотите запустить ее как решение Web Internet, это продукт для вас. В этом примере обсуждается корзина для покупок VPASP, но она будет работать для ЛЮБОЙ версии Access и для ЛЮБОЙ версии SQL Server с SQL 2000 на SQL 2008.
Я заканчиваю разработку универсального процесса преобразования обновления базы данных, включающего автоматическое преобразование. структур таблиц доступа, представлений и индексов в системе покупок VPASP или любой другой системе доступа к их эквивалентам в SQL Server 2005/2008. Он запускается прямо с вашего сервера без необходимости какой-либо внешней помощи со стороны внешнего персонала или консультантов.
После создания клона ваших таблиц, индексов и представлений Access в SQL Server эта процедура миграции данных будет выборочно переносить все данные из вашего Access таблицы в ваши новые таблицы SQL Server 2005/2008 без необходимости передавать кому-либо свою фактическую базу данных Access, содержимое таблицы или свои пароли.
Вот часть процесса обратного проектирования, выполняемого в системе с почти 200 таблицами и почти 300 индексов и представлений, которые проводятся в качестве приемочного теста системы. Работа все еще продолжается, но основные части уже готовы.
http://www.21stcenturyecommerce.com/SQLDDL/ViewDBTables. asp
Я выполняю автоматизированный обратный инжиниринг DDL таблиц доступа (язык определения данных) и конвертирую их в выражения DDL, эквивалентные SQL, поскольку структуры таблиц и даже дополнительные таблицы могут немного отличаться для каждого клиента VPASP и для каждой версии VP -ASP out there.
Я заканчиваю фактическую процедуру преобразования данных, которая будет переносить данные из Access в SQL Server после того, как эти новые таблицы SQL будут созданы, включая любые представления или индексы. Он полностью написан на ASP, с использованием сценариев VB, объекта файловой системы (FSO), объекта словаря, XML, DHTML, JavaScript прямо сейчас и работает довольно быстро, как вы увидите на базе данных SQL Server 2008, просто ради пример.
На реконструирование почти 500 различных объектов базы данных уходит примерно 15-20 секунд. Всего может быть более 2, sales@designersyles.biz (Это демонстрационный сайт VP-ASP)