Проблема что называется "не ждали".
Информация типа "String" может быть типа COMPANY INT ' L
Соответственно подпав под код типа
вылетит с ошибкой

Syntax error (missing operator) in query expression "COMPANY INT'L",next field='lala......

Использовать одинарную кавычку логически не запрещено, запретить я это вообще не могу, ибо инфо для поля берется вообще из внешнего источника.
Пофиксил пока путем замены ' на пробел при исходном считывании, но чувствую что это лажа и может стукнуть в любом месте.
Потому как например если the'Vasja то от the Vasja не убудет, а если это mailto:the'Vasja@bossserver.com, то "the Vasja" черта с два получит этот mailto при таком методе затыкания.

Т.е. как грамотно это лечить?

mds_world,

Вы вот на это намекаете?


И использовать везде, где составляются SQL-expressions c конструкциями
=> замена на
" Так? Подвоха нигде нету?
===
> а в почтовых адресах вроде изначально незя юзать эту ковычку и остальные символы
мало чего в RFC написано. Дураками одинаково могут быть и программисты, и пользователи. Подозреваю что в мыле то как раз это очень даже и может быть использовано. Отклонение от стандартов не должно являться поводом для вылета проги.
Если в русском апостроф обычно не используют, то для француза это милое дело.

Antonariyпользователь, юзающий апострофы в адресе, и разработчики почтового клиента и почтового сервера, не пресекающие это дело. И даже в этом случае остальные, умные почтовики, уважающие rfc, будут резать письма с кривыми адресами, В общем, такая ситуация не жизненна.
По крайней мере правильно получить отбой (в логе) от "умного почтовика, уважающего rfc"
а не crash моей программы от некорректного SQL запроса. Не так ли?

В моем случае удаленный (не юзающий прогу человек) в идентификаторе своего факса FaxID написал именно типа
COMPANY INT'L
-название своей компании и имел на это полное право. И моральное, и согласно RFC для FaxID. Он дурак? Думаю нет.
Прога эту строку залогировала в БД, и при след. запросе тупо использовала WHERE ...field = 'COMPANY INT'L'. И соотв. вылетела.
Причем, будучи запущенной как "сервис NT" (естественно через 3D-сторонний компонент, не самому же сервисы на VB писать), на экран ничего не выдавала. И спасибо кастомеру, что пустил меня через RDP "глянуть на ето" и у меня хватило мозгов понять причину.

Можно конечно искажать данные пробелами или пустыми местами. Но во-первых, это свинство - искажать название компании, а
во-вторых, заранее неизвестно на какого дурака/не дурака, на какое RFC, и в каком поле нарвешься.

Посему таки потратил время и во всех запросах и местах поменял str на DblApo(str), даже там где ' по определению не может быть.
И очень надеюсь что правильно сделал, и еще буду проверять в других компонентах проги.

AntonariyСамое правильное это добавлять/редактировать данные через рекордсет.
rs("field").value = стопицотапострофов и нулевая вероятность нарушения синтаксиса.
Раньше я только так и делал, ибо по-другому не умел.
Видите ли, в моем случае это означает еще раз сесть и переписать все управление данными.
Я имплементировал БД и решил использовать SQL-запросы + execute (спасибо Shocker.Pro, подсказал про execute).
Я думаю фикса с удвоением кавычек достаточно.
Особенно если учесть что проблема всплыла лишь через 3 месяца после релиза с указанной ошибкой, т.е. вероятность "столкновения 3-х дураков" действительно ничтожно мала. Но тем не менее столкновение наконец произошло, следствие было проведено и открученная гайка найдена и приварена.

HandKot,

у меня в БД секретностей нет. Она используется исключительно для удобства как компонент проги и на локальном компе, в ней нет и по определению не может быть "секретных данных". Раньше вообще использовались txt-файлы.
Вылет программы из за досадной ошибки с апострофом- плохо.
А чего ради городить огород?
И потом я достаточно долго боролся с синхронным обновлением базы (динамика критична), я не уверен что если я напереписываю коды, то не придется опять сидеть и "фиксить" кучу других неинтересных (но критичных для проги) проблем. Оно мне надо?

Мне гораздо более важно внедрять новые идеи и ф-ции за кот. люди готовы платить.
Ну да, всякие стили и внешний вид также важны, изуродованная VB6-256цветная классика негативно действует на психику юзера на win7 или висте, но вроде основные приемы освоили (и продолжаем осваивать).