Много вопросов:
у вас есть исходный файл MDB? Я не могу вспомнить, если создание MDE не удается, если связанные таблицы неправильно подключены. В любом случае, если вам понадобится изменить приложение, вам понадобится исходный файл MDB.
в сообщении об ошибке должно быть указано имя отсутствующей таблицы.
знаете ли вы, когда сообщается об ошибке? Может быть любое количество мест, где простая замена таблиц, связанных с серверной частью Jet MDB, ссылками ODBC на сервер ничего не исправит. Например, если в коде присутствуют какие-либо сохраненные запросы или SQL-код, который обходит связанные таблицы и использует строку прямого соединения, это может привести к ошибке, как вы видите.
в отношении ответа разработчика, что «я должен переписать приложение, чтобы не использовать Jet Engine ...», либо вы неправильно поняли то, что он сказал, либо ваш разработчик совершенно некомпетентен. Или оба, я думаю. Jet очень хорошо работает с таблицами, связанными с ODBC, и если вы используете внешний интерфейс MDB, невозможно полностью исключить Jet, так как MDB - это файл данных Jet. Желание устранить Jet в основном исходит от людей, которые не могут научиться правильно его использовать.
Мне кажется, что вы получаете необработанную ошибку, но недостаточно информации о том, что ее вызывает. Вам нужен фактический MDB для устранения неполадок, так как код не отображается в MDE, поэтому нет способа выяснить, каков реальный источник проблемы. Если ваш разработчик не даст вам MDB, вам нужно проверить контракт, в соответствии с которым было разработано приложение - если вы согласились позволить ему контролировать исходный код, вы в основном в его власти и должны уволить любого, кто отписался на что. Для чего стоит, когда я поставляю MDE клиенту, они также получают полный MDB. Как правило, они ничего с этим не делают, но если я больше не буду доступен для дальнейшей работы по разработке, у них есть исходный код, который они могут дать кому угодно.
И, наконец, я думаю, что очень маловероятно, что даже если ваше приложение заработает, простое увеличение даст много преимуществ с точки зрения производительности или стабильности. Это правда, что очень часто 90% или более приложений с увеличенными размерами будут работать без изменений, но остальные 10% могут быть очень проблематичными. Часто вам нужно перенести определенные операции на серверную часть, чтобы добиться эффективности, которую предлагает серверная часть. Это означает, что ваше внешнее приложение необходимо реструктурировать, чтобы оно работало лучше с вашим увеличенным внутренним интерфейсом. Степень, в которой это верно, будет отличаться от приложения к приложению, но очень редко абсолютно все работает без изменений.