Как я могу интегрировать пользовательский интерфейс MS-доступа с веб-средой .Net - PullRequest
1 голос
/ 18 апреля 2011

У нас есть устаревшее программное обеспечение, которое было встроено в MS-Access (UI), но в качестве сервера базы данных использовалось Sqlserver 2005.
Пользовательский интерфейс в Ms-Access получил меню с различными пунктами меню.Но у некоторых пунктов меню пока нет экранов (неполных).Поэтому мы решили перейти к среде .net (т.е. к веб-приложению .net).Вот мой главный вопрос.

Во-первых, я хочу начать работу с экранами в .net (веб-приложение .net), которые являются неполными для пунктов меню в MS-Access.Во-вторых, я закончу другие экраны, которые сейчас работают в интерфейсе MS-Access.Итак, как я могу использовать / вызывать экраны веб-приложений .net, когда пользователь нажимает на пункты меню в интерфейсе MS-Access.

Пожалуйста, предложите мне.

Спасибо

1 Ответ

3 голосов
/ 18 апреля 2011

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

Скорее всего, вы можете запустить любую веб-форму или веб-сайт или любой URL-адрес, на котором работает клиент Access.ваш рабочий стол.Код для запуска этого URL:

Application.FollowHyperlink "path to web form or site goes here"

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

Приложение становится полезным, поскольку все части приложения могут тесно общаться.друг другу.Доступ является отличным инструментом RAD, поскольку он легко запускает отчет, другую форму и передает информацию.И все это приложение может легко делиться общим кодом и процедурами, которые позволяют вам выполнять полезные бизнес-задачи.

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

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

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

Однако вы МОЖЕТЕ создавать веб-формы в Access 2010. Другими словами, вКлиент Access позволяет создавать как клиентские формы, так и веб-формы.Клиентские формы могут вызывать и использовать веб-формы (они запускаются на клиенте) как обычные формы и такие вещи, как, например, условия работы и т. Д.).При публикации в Интернете запускаются ТОЛЬКО веб-формы.Вот видео моего приложения доступа, и обратите внимание, как на полпути я запускаю те же формы в веб-браузере:

http://www.youtube.com/watch?v=AU4mH0jPntI

Однако, вышеупомянутая способность вДоступ прямо сейчас не может работать с сервером SQL, и должен использовать SharePoint (или предстоящий офис 365).

Поэтому нет сомнений в том, что концепция перемещения кусков и частей из приложения в веб-интерфейс имеет смысл (поэтому ваша концепция не перемещать ВСЕ приложения в Интернет имеет смысл).Однако части, перемещаемые в Интернет, должны иметь смысл как веб или отдельно и не требуют интеграции с клиентскими формами (по крайней мере, во время использования).

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

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

И последнее, но не менее важное: вы, безусловно, можете создать набор веб-сервисов (бизнес-код приложения и логика, отличную от пользовательского интерфейса) на веб-сайте .net.Этот отдельный бизнес-уровень может затем использоваться как клиентскими формами Access, так и веб-формами.Однако, опять же, такая настройка, скорее всего, предполагает, что вам лучше в любом случае создать приложение как веб-ориентированное, так как веб-формы могут общаться и использовать бизнес-код с большей легкостью, чем клиентские формы - только здесь снова исключение, если вы используетеПолучите доступ к веб-службам, и веб-формы, или клиентские формы смогут использовать хранимые процедуры и бизнес-подпрограммы, которые вы пишете для запуска на стороне сервера.

И последнее, но не менее важное: возможно, ваша проблема (проблемы) решена за счет увеличения числа подключений, а нена самом деле потребность в веб-основе?Я рассматриваю этот вопрос в моей следующей статье.

http://www.kallal.ca/Toweb/Index.html

...