Вы действительно не хотите какой-то тип автоматического преобразования в любом случае.Причина в том, что вам нужно ИЗМЕНИТЬ, как вы сделали некоторые из этих вещей, чтобы работать с изменением архитектуры, которое происходит при переходе от одной системы разработки к другой.
Автоматическое преобразование, вероятно, не стоит того, так как частокак все было сделано в предыдущей системе, будет сделано по-другому в новой системе.Например, когда люди пришли из приложений FoxPro на базе DOS (текстовый экран) в Access, разработчик должен был сделать два существенных изменения:
1) В Access нет номеров записей
FoxPro (который был dBase-совместимым клоном) был основан на том, что являлся системой баз данных на основе пользовательских файлов.Так что это была система, разработанная с нуля для работы на вашем персональном компьютере.Это означало, что файл и система программирования использовали последовательные записи из файла на жестком диске.Эта модель была очень похожа на обработку данных перфокарт.И я должен отметить, что в этом типе модели нет ничего плохого, но программные подходы и конструкции, которые вы использовали для обработки данных перфокарты, несколько отличаются по сравнению с интерактивными многопользовательскими системами.
Что является ЗНАЧИМЫМ и наиболее важным здесь, находится на концептуальном уровне, когда вы пишете программное обеспечение внутри Access, а затем записываете номера или так называемый порядок записи вызовов в качестве концептуальной идеи, которая при написании программного обеспечения НЕ актуальна.Однако в Foxpro предположение о порядке записи было законным предположением.Это изменение архитектуры.Я помню еще в начале 90-х, что на многих форумах один из первых вопросов, которые задавал давний разработчик Foxpro:
Почему у доступа нет номеров записей, как у Foxpro?
Ответ был прост, и этот ответ был / был Access рассматривает данные как большой огромный неупорядоченный набор данных.Другими словами, если вам нужен какой-то порядок в ваших данных, вам нужно было добавить что-то вроде номера счета, возможно, даже отметку времени или что-то еще.Для чего-то вроде субформы в качестве общего правила вы можете использовать автоматический номер, но этот автоматический номер никогда не должен просматриваться пользователями.Независимо от того, что вам пришлось использовать SQL-запрос, который говорит, в каком порядке вы хотите.
Еще одна важная деталь - если вы добавите 10 записей в таблицу (даже в однопользовательском режиме), если вы затем получите эти 10записей из этой таблицы, вы НЕ МОЖЕТЕ предполагать, что порядок записей будет таким же, как при их добавлении.Другими словами, если вам нужен определенный порядок, вы должны отсортировать эти данные по некоторому столбцу.Это предположение, которое FoxPpro, или люди, которые использовали FORTRAN и перфокарты, всегда могли предположить.Такие предположения не могут быть сделаны при использовании Access.На самом деле это предположение нельзя сделать ни с какой современной серверной системой, такой как SQL-сервер.
Однако это предположение о «отсутствии» порядка записи было ЗНАЧИТЕЛЬНО важно позже в будущем.Это «допущение» означает, что ТОГДА ваш дизайн ВСЕГО доступа теперь основывался на предположениях о том, что РАЗРЕШЕНО легко переводить в многопользовательские системы ИЛИ в систему от клиента к серверу (оба нуждаются в этом предположении).к следующей или предыдущей записи (на основе номера записи), поскольку записи теперь представляют собой беспорядочный набор записей, вводимых разными людьми.Следующие две записи в этой таблице (или предыдущие) могут быть не вашими!Так что имейте в виду, что, хотя Access позволяет вам перейти к следующей / предыдущей записи внутри формы, он НИКОГДА не делает это на основе номера записи, а ТОЛЬКО на данных, которые ТЕКУЩИЕ загружены в эту форму.В FoxPro вы часто перемещаетесь, фактически используя команду, которая говорит перейти к записи 4 в таблице.
В Access мы не говорим перейти к 4-й записи в таблице.Можно сказать, перейти к 4-й записи в некоторых данных, которые мы извлекли из таблицы в форму, но эта 4-я запись не имеет абсолютно никакого отношения к фактической физической четвертой записи в таблице.Небольшое изменение, но то, которое требовалось для многопользовательских систем, которые мы начали использовать 10 лет спустя (поэтому небольшое изменение в программном обеспечении дало преимущества спустя 10 лет!).
Как правило, эта архитектура илиФилософская концепция порядка записи в таблице не имеет большого значения для большей части программного обеспечения, которое вы пишете, но если позже вам понадобилось использовать SQL-сервер, то это было большое дело.И я должен отметить, что, поскольку ваше программное обеспечение написано с использованием SQL, то, по крайней мере, в этом отношении вы в хорошей форме.
Однако для тех, кто писал приложения более 4-5 лет на основе этой простой записиИсходя из предположения о порядке, он должен быть полностью RE-архитектурным для многопользовательской среды или даже для Access.
Я должен отметить, что FoxPpro в конечном итоге стал блестящим объектно-ориентированным инструментом разработки клиент-сервер, но ему пришлось пройти через значительную метаморфозучем оригинальная архитектура и дизайн, которые были в типичном приложении FoxPro.
2) Программирование на основе событий
В этих старых текстовых системах вы обычно писали одну крупную мажорную программу.программа запуска с включенной системой главного меню.Выбор пункта меню затем, возможно, приведет к переходу к разделу в основной программе или, возможно, к ответвлению и вызову другой части или части приложения.Однако следует отдать должное FoxPro и большому количеству инструментов разработки, которые имели некоторые типы настройки событий, но они не были идеальными.В любом случае, лучше всего повторить то, как будут работать эти экраны и пользовательский интерфейс, при отбрасывании текстового пользовательского интерфейса - это ОЧЕНЬ много в случае с новым сенсорным и жестовым интерфейсом, который мы сейчас видим, например, на смартфоне или iPad.
В программировании, управляемом событиями, у нас, как правило, нет такой большой программы запуска.И у нас также нет большой базы кода для системы главного меню.В программировании, управляемом событиями, у вас есть код, который ОТВЕЧАЕТ на щелчок пользователем.Или у вас есть код, который отвечает на сохранение записи.Или даже переход к следующей записи.
Таким образом, в программировании, управляемом событиями, вы нажимаете на кнопку, тогда довольно МАЛЕНЬКИЙ бит кода будет реагировать на событие пользователем (в данном случае щелчком мыши).Таким образом, этот тип программирования является тем, что мы называем программированием, управляемым событиями.
Внезапно ваше приложение теперь не управляется или запускается одной большой большой основной программой, но на самом деле это целая куча, немного крошечнаянебольшие программы, сшитые вместе с помощью управляемого событиями кода.
Для людей, пришедших из среды на основе DOS, или даже QuickBasic, GW-basic или даже многих из более старых систем баз данных на основе текста, с одной большой программой запуска с некоторымиСистема меню была общей.
И наличие большой программы для «редактирования» одного экрана ввода данных было обычным делом.
Теперь такие конструкции перевернуты, в которых теперь должны запускаться ваши меню и события щелчков и вызываться код,Таким образом, эти очень маленькие подпрограммы будут вызывать другие биты кода, чтобы приложение могло работать.
Основной причиной такого изменения архитектуры стало введение мыши и графического интерфейса пользователя. Другими словами, просматривая форму ввода данных, вместо того, чтобы переходить к следующему полю в сложной форме ввода данных, пользователь теперь может щелкать по многим различным вещам и даже щелкать по строке меню. Таким образом, они могут нажать на ЛЮБОЕ место в форме. Это означает, что наличие одной большой программы для запуска и поддержки ввода данных формы было / невозможно. Если ваш код ожидал ввода в поле «Компания», то как можно было бы выполнить код, когда пользователь щелкнул пункт меню? Так как пользователь может делать много вещей в совершенно ином порядке, чем ожидал бы оригинальный программист, нам нужен другой способ написания кода.
В конце дня с графическим интерфейсом ветвление кода стало слишком сложным для разработчика. Следовательно, концепция событийно-ориентированного программирования родилась для решения этой дилеммы. Другими словами, наш код теперь запускается и реагирует на действия пользователей, и наш код не ожидает следующего пользовательского ввода в некоторой строке кода.
Опять это было небольшое изменение архитектуры, но многие разработчики боролись с этим концептуальным изменением в подходе к разработке программного обеспечения. С другой стороны, все эти изменения произошли в начале 90-х годов.
Следующим большим изменением курса стало объектно-ориентированное программирование. Доступ действительно позволяет создавать объекты классов, но это не полная система OO.
Сегодня следующая большая проблема, изменения и архитектура - это возможность создавать веб-системы. Опять миллионы изменений происходят из-за того, что они «решают» разные программы для разработчика. Access 2010 позволяет создавать веб-системы уже сейчас, и это изменение концепции и архитектуры является БОЛЬШЕЙ проблемой, чем изучение нового макроязыка, который есть у нас для разработки веб-форм с помощью Access. Так что «изменение» в дизайне программного обеспечения должно произойти снова.
Я должен отметить, что эти серьезные изменения в отрасли происходят примерно раз в 10 лет или около того.
Суть всего вышесказанного в том, что даже если бы была какая-то автоматизированная система преобразования, она действительно НЕ работала бы очень хорошо, потому что архитектура систем очень разная. Тебе будут мешать все старые предположения.
Я также заметил, что вы спрашивали об использовании Access на различных форумах Access примерно два года или даже больше? Кажется, вы ищете волшебную серебряную пулю, которая решит ваши проблемы. Там нет ни одного!
В конце дня вам нужно сесть и приобрести базовые навыки доступа или нанять кого-нибудь. Вам необходимо изучить систему, которую вы собираетесь использовать, и тогда придумаете дизайн, который работает с Access и «есть» для Access.
Я должен отметить, что дизайн, который вы выбираете для Access, не обязательно должен работать с vb.net. Так что не пытайтесь взять существующий дизайн и поставить квадратный колышек в круглое отверстие. То, что работает в одной системе с точки зрения пользовательского интерфейса, НЕ будет работать в других системах.
Я думаю, вы слишком долго дурачились здесь. О единственной хорошей части задержки так долго, теперь вы должны подумать, если вы хотите принять набор инструментов, который позволяет некоторую веб-интеграцию с приложением?
Office 365 отлично работает с веб-публикацией Access, но для сложных зрелых приложений, я думаю, веб-сторона несколько слабая (но вы можете писать гибридные приложения с Access 2010 сейчас). Вот видео из Сети доступа в действии:
http://www.youtube.com/watch?v=AU4mH0jPntI
В приведенном выше примере я запустил приложение в веб-браузере. Это приложение было на 100% встроено в Access, включая логику и код триггера таблиц (не использовались сторонние инструменты или система кодирования - использовался ТОЛЬКО Access).
Рассматривая технологию прямо сейчас, возможно, у вас есть этот прогон на iPad, когда они ходят по магазину? Здесь есть много новых вариантов для программного обеспечения, но если вы сидите без дела еще 2-3 года, то вам нужно будет использовать что-то другое, кроме iPad и какую-то «другую» новую систему.
Вы, безусловно, можете писать свои приложения как более «сенсорные» в Access. Однако некоторые новые действия, основанные на жестах, не передаются в сеть. Например, мы не можем отключить ввод с клавиатуры в поле со списком, и эта возможность ДЕЙСТВИТЕЛЬНО помогла бы приложению Access, работающему на iPad, если бы мы могли. Причина в том, что когда мы нажимаем или нажимаем на поле со списком на iPad, на экране появляется всплывающая программная клавиатура, и мы НЕ хотим этого. А некоторые из действительно приятных сборщиков жестов и т. Д. Не переводятся на iPad на веб-сайтах (они все-таки хотят, чтобы вы писали собственные приложения!).