желание переместиться вверх от доступа мс, размышление .NET? Visual Studio?

У WPF довольно крутая кривая обучения, особенно из Access. WinForms был бы более простым путем, но все же это шаг вперед по сравнению с Access. Однако и WPF, и WinForms имеют конструкцию форм с перетаскиванием, и, если вы знаете достаточно VB.NET для преобразования бизнес-логики VBA, вы более чем на полпути. :)

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

Пока клиенты не используют общую базу данных, приложение .NET WPF / WinForms со встроенной базой данных, похоже, будет работать нормально.

Вы, вероятно, могли бы даже разработать что-то, что работает как на ПК с Windows, так и на вашем компьютере Linux, используя Mono (вы бы застряли с подмножеством WinForms ... но для простого бизнес-приложения в этом нет ничего плохого).

Думали ли вы о Appcelerator Titanium или чем-то подобном? Вы создаете богатый графический интерфейс с использованием веб-технологий (HTML, CSS, javascript и или python) и компилируете его в настольное приложение.

Преимуществом будет то, что вы можете разрабатывать в Linux, а окончательное тестирование и развертывание проводить только в Windows.

Тем не менее, писать производственное программное обеспечение в качестве новичка нелегко. Особенно сложной может оказаться работа с ошибками. Будьте умны и думайте о том, "что может пойти не так, когда пользователь делает это", и проверяйте вводимые данные.

В такой среде, как эта, вы не можете ошибиться с VB/C#. Попробуйте различные редакции VS Express.

Если вы хотите что-то, что немного больше подходит для Linux, подойдет Python и практически любой кроссплатформенный GUI фреймворк (QT, или wxpython).

EDIT: Затем есть база данных. Я бы посоветовал sqlite, если вы хотите изучить что-то кроссплатформенное. Если придерживаться мира Microsoft, есть SQL server compact.

В такой бизнес-среде, как эта, приложение .NET, вероятно, будет более удобным для обслуживания (после того, как вы уйдете, и т.д.), чем что-либо, что не является полностью Microsoft.

Я бы сказал, что веб-приложение (C #) с SQL Express на сервере, но это только я

Я сказал это в комментарии, но я повторю это как ответ:

Если вы посмотрите на будущее Access, оно будет ярким. MS вкладывает в это большие средства. Access 2010 в сочетании с Sharepoint 2010 предлагает довольно удивительные преимущества, и все это вы делаете без какого-либо VBA (вместо этого вы используете новые мощные макросы, которые имеют переменные, ветвление и перехват ошибок). Вы можете сделать это с клиентским доступом и без Sharepoint, или вы можете опубликовать его в Sharepoint, и приложение будет запускаться в веб-браузере.

Я предполагаю, что одно из двух должно произойти в отношении языка программирования в Access во время выпуска 2-3 версий Access после 2010 г .:

1. VBA по-прежнему поддерживается, и вся работа переходит в макросы. В конце концов, макросы стали предпочтительным методом для всего программирования в Access, а VBA в конечном итоге устарел и окончательно исключен. Поскольку к этому моменту макросы становятся настолько универсальными и надежными, язык программирования не заменит VBA.

2. тот же сценарий, за исключением того, что .NET поэтапно заменяет VBA.

Я бы надеялся на № 2, но это полностью зависит от взгляда Microsoft на то, что такое Access, т. Е. В первую очередь от инструмента для конечного пользователя с расширяемостью вверх (№ 1) или от инструмента для конечного пользователя и универсального инструмента разработки с неограниченная расширяемость (# 2).

Я хочу сказать, что вы можете остаться с Access, пока не использовать VBA (если вы его действительно ненавидите) и, вероятно, в итоге получите работоспособное и стабильное приложение.

Однако мои оговорки по поводу макросов очень сильны, поскольку я считаю, что их очень трудно поддерживать из-за их автономного характера.Код VBA довольно прост в навигации и понимании, потому что он скомпилирован и потому что есть полнофункциональная IDE. Макросы гораздо более разделены, и их сложно отследить взаимосвязи между ними и объектами, в которых они используются. Добавьте встроенные макросы, добавленные в A2007, и это станет еще более сложным. Я не знаю, занимается ли команда Access этим или нет, но для меня это реальный шаг назад с точки зрения управляемости, особенно если усиление макросов приводит к тому, что VBA устаревает, а затем не заменяется соответствующим мощным язык программирования с хорошей IDE.

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

Если вы работаете только над небольшими внутренними приложениями, посмотрите на Visual WebGUI - вы получите очень похожую на VB6 среду разработки для веб-приложений. Однако я бы не рекомендовал его для больших и/или публичных приложений.

Исходя из ваших критериев, я бы использовал PyGtk и Glade. Gtk хорошо поддерживается в Windows и Linux, и я сделал больше за меньшее время с Python и GTK, чем с любой другой комбинацией языка / инструментария.

Если вы хотите переосмыслить это в Интернете, взгляните на ExtJS, который предоставляет множество настольных веб-элементов управления, и у них есть конструктор графического интерфейса.

Для базы данных я бы пошел с Postgresql или SQLite. Имейте в виду, что SQLite имеет некоторые серьезные ограничения, когда дело доходит до параллелизма, что может быть проблемой в зависимости от дизайна вашего приложения и количества пользователей.

MS Access - настольное приложение для работы с базами данных. На один шаг выше, скорее всего, будет SQL Server Compact Edition (SQLCE) , который работает как часть вашего приложения (в отличие от SQL Server Express или более поздней версии, которые работают как системные службы). Я с большим успехом использовал SQLCE в нескольких приложениях, а Microsoft использует его в Visual Studio 2010 для нового кэша Visual C ++ IntelliSense, потому что он легкий и отлично работает.

Несмотря на то, что я читал в некоторых источниках, SQLCE плохо взаимодействует с Entity Framework. Он работает , но отлично работает с LINQ-to-SQL и соответствующим конструктором. Тем не менее, я лично рекомендую вам рассмотреть возможность объединения следующего в качестве замены:

• Данные: SQL Server Compact Edition
• Данные / код: LINQ-to-SQL
• Язык программирования: C #
• Структура приложения: WPF
  • Личное замечание: WPF действительно требует обучения, но в первую очередь это сложно для людей, которые долгое время работали с другими фреймворками (MFC, WinForms и т. Д.). Подберите хороший справочник, и вы сможете продуктивно работать в кратчайшие сроки, к тому же вы будете опытны в технологии, которую люди перемещают в сторону , а не прочь .