Front-End для миграции MS Access?

Вы не найдете серверного класса двигатель, к которому также прилагаются инструменты проектирования интерфейса рабочего стола. Все большие серверные движки ожидают, что вы будете использовать что-то вроде C++, C#, Java или PHP для создания интерфейса.

Я тоже хотел бы увидеть инструмент обновления для доступа, который бы выдавал некоторые базовые формы C# и общался с эквивалентной базой данных SQL Server. Похоже, что это принесло бы Microsoft большой доход, потому что они могли бы использовать это как способ продать клиентам полноценный SQL Server.

IIRC, может быть способ сообщить клиентской части Access, чтобы она разговаривала с SQL Server, или изменить таблицы, используемые клиентской частью Access, чтобы они действительно были связаны с таблицами в SQL Server, или что-то в этом роде, но я никогда не мне пришлось использовать эту функцию.

Несколько лет назад я переключил серверную часть одного приложения с MSacces на MSSQL. Сохранил интерфейс, потому что он работал хорошо, и я не нашел ничего более простого в использовании / изменении.

Я никогда не видел переводчика MSAccess -> C#. Однако вы можете найти переводчик MSAccess на VB6 (их синтаксис примерно похож), и оттуда есть переводчики VB6-> VB.Net (и даже переводчики VB.Net -> C#)

Is there anything that will replace the front end part of MS Access?

Может Kexi?

Вы можете проверить Приложение Oracle Application Express. Это бесплатно и ориентировано на разработчиков Access.

У него также есть помощник по миграции, через который вы запускаете свою базу данных Access, он обрабатывает данные и формы, переносит все в базу данных Oracle (это работает с бесплатной базой данных Oracle XE и устанавливается по умолчанию) и создает веб-формы. для вашей базы данных Access.

Так что, в конце концов, у вас будут базы данных Access в Интернете, данные в Oracle и приятный веб-интерфейс для их расширения.

Что касается Oracle, инструмент неплохой. Вы можете подписаться на бесплатный экземпляр, чтобы поиграть с здесь.

Вот документ, в котором объясняется, как вы переносите базы данных Access.

Итак, кроме личной неприязни, зачем заменять интерфейс Access? Может быть легко сделать для некоторых (простых) баз данных, но большинство приложений Access в реальном мире имеют большую сложность.

Конечно, есть множество причин для обновления серверной части (масштабируемость, производительность, повреждение базы данных, блокировка пользователя). В Access даже есть встроенный инструмент «мастер обновления», который позволяет отделить формы и логику от данных и обновить данные до сервера MS SQL. Если хотите, используйте этот мастер для обновления серверной части до SQL Express, а затем вручную перейдите на другую платформу базы данных.

Надеюсь, это не слишком далеко от темы, но иногда все, что вам нужно сделать с Access, это:

1. Обновите серверную часть (как мы уже обсуждали)

2. Всегда проверяйте, что интерфейсы заблокированы (только для чтения)

3. При необходимости создайте разные интерфейсы для разных ролей пользователей (в качестве меры безопасности).

4. Если возможно, скопируйте внешние интерфейсы локально на каждую рабочую станцию ​​из соображений производительности. Возможно, вам понадобится сетевой сценарий для проверки наличия новых версий интерфейса.

У меня нет прямого опыта работы с ним, но я нашел инструмент преобразования доступа к ASP.Net под названием «Access Whiz» в http://www.microtools.us/

@BradC

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

Мы обнаружили, что практически любой путь обновления потребует значительных изменений кода. Все эти инструменты хороши для того, чтобы поддерживать аналогичный графический интерфейс исходного приложения. В их коде не было объектной структуры, только набор служебных функций, которые были сброшены на каждую страницу, чтобы имитировать способ, которым Access обеспечивает навигацию по записям. Если у вас большое количество форм, получение их решения и реализация собственного потребуют некоторой работы и тонны операций по поиску и замене.

Мы были настолько разочарованы производительностью MicroTools, что начали писать собственный конвертер. Мы создавали более качественные формы ASP.NET, чем они были после недели написания кода.

У меня есть другая точка зрения, которую вы должны рассмотреть. Ваша главная проблема в том, что он скрывает логику, а данные и приложения разбросаны по всей организации.

К сожалению, я не знаю инструмента RAD (быстрой разработки приложений), который был бы так же прост, как Access, для создания функциональных форм.

Однако я бы рекомендовал вам больше сосредоточиться на возможности централизации ваших данных и логики и по-прежнему разрешить доступ в качестве внешнего интерфейса. Я поддерживаю продукт базы данных под названием Advantage Database Server, который поддерживает правила RI (ссылочная целостность), хранимые процедуры, триггеры и т. д., Которыми можно управлять на центральном сервере, таким образом предоставляя вам всю логику. Затем эти внешние интерфейсы доступа могут связываться с серверной частью данных с помощью ODBC или OLEDB. Если вы перешли на подобное решение, то позже в будущем у вас будет возможность писать другие приложения, такие как .NET, PHP, JDBC и т. д., Которые связаны с теми же данными, при постепенном отказе от внешних интерфейсов Access.

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

Мы использовали внутреннее приложение на основе MS Access в качестве интерфейса к базе данных MySQL. Мы столкнулись с много проблем и в итоге переписали все приложение на CodeGear Delphi 2007 для Win32. Это был большой успех, хотя миграция потребовала довольно больших усилий (обучение / наем пары программистов Delphi, покупка некоторых сторонних инструментов). Тем не менее, я могу искренне рекомендовать Delphi. И, AFAIK, интеграция с серверной частью MS Access, безусловно, возможна --- я однажды написал приложение Delphi, которое делает именно это, и мне потребовалось всего пару дней, чтобы получить полнофункциональную версию!

Я понимаю, что это полное решение для программирования, поэтому вы определенно потеряете часть простоты использования MS Access для создания интерфейсов. Опять же, вы можете собрать приложение базы данных на Delphi за 10 минут, не написав слишком много кода - без шуток! А после выпуска 2009 года этот язык снова стал более популярным ...

Microtools предлагает Access Whiz, набор инструментов преобразования Access. Он состоит из конвертеров доступа к ASP .NET (VB / C#), конвертера доступа к VB6, конвертеров доступа к WinForms (VB .NET / C#) и конвертера доступа к Crystal Reports. Более подробную информацию и демонстрационные версии можно найти на http://www.microtools.us.

Вы также можете взглянуть на Жар-птица

Вот путь к мигрировать (нужен Delphi)

Я тоже нахожу этот MDB2FDB

Сколько из тысячи файлов Access вас попросили поддержать? Я предполагаю, что меньше 100. Зачем перестраивать приложение, которое А) никто не использует Б) отлично работает именно так?

Вам необходимо начать политику, согласно которой для большой организации является приемлемой практикой разрабатывать собственные приложения в устойчивой, масштабируемой, надежной среде yadda yadda yadda. Определите приложения Access, которые, по вашему мнению, являются критическими или уже давно выросли, и просто поработайте над ними.

Будьте готовы справиться с ожиданием получения быстрых и грязных маленьких приложений в кратчайшие сроки. Вам нужно будет показать им преимущества ваших новых приложений.

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