Идея – поюзать ф-ю (не связывая таблы). Топорно это так (у меня)
В источник данных рисунка пишем что-нить типа:

(не шибко думая, как это изячно оформить)
где в модуле:

(В терминах примера)

Дык вы же _смотрите_ в табличке [Picture] а там записей 2-3. Посему ф-я не должна сильно подтормаживать. (именно поэтому не сделано иначе). /на всякий штамп есть его область применения/. Т.ч. это не аргумент.

(Обычно при сомнении такого рода пишете альтернативку, вставляете штамп времени типа Debug.Print Time в соответствующие места и тестируете)

А если уж "по модному" - запросто можно загрузить recordset в оперативку (или даже в массив)(например при открытии формы), и прописать ф-ю, которая юзает рекордсет seek-ом (вместо DlookUp) (или по индексу - если загрузили в массив). Тормоза если и будут, то из-за me.recalc (необходимости пересчитать все записи формы). Зато освобождаетесь от искуственного поля связи. (Не говоря о вашей проблеме).

ну чё ты паришь? этот вариант у меня работает в указанном тобой примере визуально быстрее, чем 3-й (с записью поля связи) из этого же примера. оно и понятно - табличка picture может в кеше сидеть, т.ч. дисковых операций зримо меньше. Это на глаз. И никаких тебе мерцаний не наблюдается. Так-то. О загрузке таблы картинок в память ручками (и юзании самостийной ф-ии) я тебе уже намекал.

Вот про адп не скажу не возился. можно ли в ем иметь свою или подключенную таблу mdb формата? для картинок. Если нет - то как запихать "связанный объект" в SQL... но ежели запихали, то при работе с SQL метод зачтения таблы (!маленькой! [picture] - в примере) один раз в массив (память) и юзание функции будет заведомо быстрее, чем писать в поле связи (на стороне сервера!). Ага. Изум тут не в dlookup, а в CurRec(). Ключ тока нужен. А реализация приведена для примера - такая, какая вполне работает на модельной задаче.