Местами администраторВыполняю запросы к SQL серверу через ODBC при помощи примерно такой конструкции:
tVdok='"'+'select * from fn98'+'"'
nResult=SQLPREPARE(nShandle, &tVdok, "fn98")
ЗАЧЕМ тут эти танцы с бубном? ЗАЧЕМ здесь макроподстановка? Уберите ее и все наладится.

Местами администраторконкретно в этом случае макроподстановка не нужна, но это ведь примерная конструкция запроса, если его текст привести полностью, то макроподстановка еще как нужна.Не надо рассказывать сказки. Для формирования любой строки макроподстановка не нужна. Точка. Лучше внимательно посмотрите на text ... endtext, особенно опцию textmerge.

Местами администраторпроходящий.Местами администраторВыполняю запросы к SQL серверу через ODBC при помощи примерно такой конструкции:
tVdok='"'+'select * from fn98'+'"'
nResult=SQLPREPARE(nShandle, &tVdok, "fn98")
ЗАЧЕМ тут эти танцы с бубном? ЗАЧЕМ здесь макроподстановка? Уберите ее и все наладится.


попробуй сам,
tVdok='select A.n1,A.d6,A.D428_2,A.D270,C.N590,B.d84,B.d87_2,d86_2,C.d3587_101,C.d3587_104,C.d3587_106,C.d3587_107,C.d3587_110,C.d250 from FN1532 A join FN1552 B on B.D270=A.D270 join FN15521 C on C.D270=A.D270 left join fn1505 D on A.n1=D.n1 and D.d83<0 where A.D789=11 and C.D09=1 and C.d250=2009'

база данных не понадобиться (до нее дело не дойдет), скопируйте все в фокс и попробуйте сохранить...1. ВНИМАТЕЛЬНО читаем статью по ссылке представленной PaulWist.
2. В качестве демонстрации предложенного text ... endtext:

Местами администраторда прочитал, но речь то была о макроподстановке, ее "убрать и все наладиться".
За ответ спасибо.Предложение попробовать мне выполнить в фоксе строку с присвоением переменной значения текстовой константы длиной боле 254 символов к макроподстановке отношения не имеет. Это ошибка писателя сей строки. Потому отсылка к статье про строки.
Макроподстановка для передачи символьного параметра функции - вредная бессмыслица, вызванная, вероятно, первой причиной - неумением работать со строками и незнание правил и ограничений в такой работе.

Местами администратор,
кстати, вызывать SQLPREPARE() для однокрано выполняемого батча - бессмыслица. Выигрыша по сравнению с простым SQLEXEC() никакого, даже проигрыш на количесвте выполняемых команд.
Вот для повторения одно и то же команды - самое то.

Местами администраторпроходящий.,
Любишь ты поучить,Не люблю, но жизнь заставляет. решения по данному вопросу предложил не ты,Оппа... И где же тут предложенные не мной решения? уперся в макроподстановку, Да, уперся. Ибо в том числе и из-за нее вылезает описанное тобой поведение.
будто я кого то убил, работает с макроподстановкой, в какой то ситуации опытным путем пришел к макроподстановке (значит без нее нельзя было),Классное доказательство. :) Можно. Любую строку можно сделать из кусков без макроподстановки. Это надо доказывать? а теперь работаю по шаблону, на ограничения не натыкался, быстродействие не падает, результат правильный - ты раздуваешь проблему из нифига.Я не раздуваю проблему, а предупреждаю любителей работать по шаблону от граблей, которые они сами себе подкладывают. Ты вот как раз и наступил именно на такие грабли. Кстати, в оценке программного кода и программ кроме работоспособности и корректности существует такой критерий, как скорость исполнения. Макроподстановка тормозит.

Местами администраторпроходящий.,

сколько проиграю - 0,001 с ?На одном вызове. Сколько всего вызовов делает программа? Например при вставке 10 000 записей? К тому же зачем делать бесполезные вещи? Из-за лени подумать?

Местами администраторigorbik,
да работает вся фигня уже давно, сейчас захотелось оптимизироватьНо ускорение работы в оптимизацию не входит. Так? :)

Местами администраторпроходящий.,
выиграть 5 секунд, это понятно, но из-за сотых-тысячных долей не стоит кричать, что я нифига не правильно использую фокс.И где был крик? Как надо было сообщить об этом неправильном использовании? Мелким невидимым шрифтом?

Местами администраторВ данном случае при небольшой длине строки запроса отлично работает и с макроподстановкой, так что грабли в данной ситуацие не "эти"
Вот именно "при небольшой". И грабли таки эти. И без макроподстановки работает еще лучше. Уж поверьте старперу, оптимизировавшему тонны показанного Вами кода. И получавшего в выигрыше отнюдь не вымышленные 5 секунд, а в разы большую скорость и уменьшение времени на минуты, часы и даже сутки. Не надо забывать про законы больших чисел и про то, что большое состоит из тысячи мелочей.

Местами администраторпроходящий.Местами администраторВ данном случае при небольшой длине строки запроса отлично работает и с макроподстановкой, так что грабли в данной ситуацие не "эти"
Вот именно "при небольшой". И грабли таки эти. И без макроподстановки работает еще лучше. Уж поверьте старперу, оптимизировавшему тонны показанного Вами кода. И получавшего в выигрыше отнюдь не вымышленные 5 секунд, а в разы большую скорость и уменьшение времени на минуты, часы и даже сутки. Не надо забывать про законы больших чисел и про то, что большое состоит из тысячи мелочей.

Сам себе противоречишь - грабли таки эти, и без макроподстановки работает еще лучше - так с макроподстановкой все-таки работает, хуже, но все-таки (-+0...1 с), согласен?Не понял.
1. SQLPREPARE() для одиночного батча - тормоз. И лишние строки.
2. Макроподстановка не может быть более 254 символов и тормоз.
3. С помощью Coverage profiler считаем реальное количество вызовов с этими тормозами и тихо офигеваем.
Где противоречие?

Местами администратор2. так ведь и без макроподстановки не получалосьКак у тебя с булевой алгеброй и математической логикой? .t. or .t. какой даст результат? Изменится ли результат если перевести в .f. только один операнд? Что надо сделать, чтобы таки результат стал .f. ?
1,3 SQLPREPARE() использую действительно один раз, но дело в том, что данные взял с сервера, отключился и программа работает автономно, следующее обновление данных дня через два, три
через лет пять пожалуй и набралось бы секунд 20-30Ну это все сначала так аргументируют свой выбор. Потом начиают работать по шаблону. Потом количество применений шаблона увеличивается. Потом прога начинает тормозить. Разбор полетов показывает, что объяснения, что мол такая конструкция тормозит всего лишь на 0.00001 сек., не выдерживают никакой критики в силу того, что РЕАЛЬНОЕ количество использования такого шаблона и, главное, количество реальных вызовов критикуемого кода, построенного по шаблону, превышает все предполагаемые разрботчиком-шаблоником пределы на ПОРЯДКИ!!! Особено если это где-то внутри большой сложной формы с кучей refresh'ей "для надежности". Зачем учится плохому? Зачем на это тратить время? Может лучше сразу по хорошему?

Игорь Горбонос
З.Ы. Так и хочется поотрывать все и приставить обратной стороной
Стесняюсь спросить где и что хочется поотрывать и приставить? :)

Местами администраторТак легко договориться и до того, что завтра конца света.
Но если в будущем соберусь писать полноценное клиент-серверное приложение, обязательно учту все пожелания, связанные с символьной строкой и макроподстановкой в случае применения SQLPREPARE() .Опять какое-то кривое понимание. Макроподстановка тормоз всегда, вне зависимости от SQLPREPARE() и прочего. В том числе и от клиент-серверности.

проходящий.Вот именно "при небольшой". И грабли таки эти. И без макроподстановки работает еще лучше. Уж поверьте старперу, оптимизировавшему тонны показанного Вами кода. И получавшего в выигрыше отнюдь не вымышленные 5 секунд, а в разы большую скорость и уменьшение времени на минуты, часы и даже сутки. Не надо забывать про законы больших чисел и про то, что большое состоит из тысячи мелочей.

проходящий.И грабли таки эти
Макроподстановка работает=.F.
проходящий.без макроподстановки работает еще лучше
Макроподстановка работает=.T.


проходящий.Уж поверьте старперу, оптимизировавшему тонны показанного Вами кода
Код измеряется в тоннах? Моего кода? (т.к. Вами с большой буквы, логично предположить, что обращение лично ко мне)

У кого проблемы с логикой и дискретной математикой?М-да, похоже без конкретных кусков кода, где макроподстановка была "необходима", не обойтись.
К тому же говрилось про два операнда, а не про один. Потому вопрос про логику и математику остается открытым.
Про тонны кода, возможно я не совсем точно выразился. Имелись в виду тонны кода, пример или образец которого и был Вами продемонстрирован. Написаны сии тонны, конечно, не Вами, но все подобные коды разительно похожи друг на друга как по стилю, так и по быстродействию.

Местами администраторпроходящий.Местами администраторВыполняю запросы к SQL серверу через ODBC при помощи примерно такой конструкции:
tVdok='"'+'select * from fn98'+'"'
nResult=SQLPREPARE(nShandle, &tVdok, "fn98")
ЗАЧЕМ тут эти танцы с бубном? ЗАЧЕМ здесь макроподстановка? Уберите ее и все наладится.


Человеку свойственно ошибаться.
проходящий.ЗАЧЕМ тут эти танцы с бубном? ЗАЧЕМ здесь макроподстановка? Уберите ее и все наладится.
Начиналось ведь с этого, опять накладочка.Опять не понял. О какой накладочке речь. Не могли бы изъясняться поточнее? И ведь речи нет ни про быстродействие, ни про логику
Просто сказано, что данная конструкция не работает из-за макроподстановки, а конструкция работает. Работает в некоторых случаях. Вам предложено решение, работающее всегда. Потом было объяснено, что макроподстановка еще и торомоз. Что не так?Это потом, дабы выкрутиться чужое решение было выдано за свое,Тынц в студию. Какое чужое решение? Где? Ткните пальцем. а когда это не прокатило пришлось докапаться до быстродействия, да уж -
В чужом глазу соринку видно, а в своем бревна не видать.Не прокатило что?
ps: Вы не слишком близко к сердцу приняли мои рассказы про хороши и плохие подходы к прораммированию на фоксе?

Местами администраторпроходящий.Оппа... И где же тут предложенные не мной решения?
Вот
PaulWist Символьные поля, переменные памяти и константы
Опять жуть. Это не решение проблемы, а описание граблей, на которые Вы наступили. И грабли эти как раз в макроподстановке и лежат. РЕШЕНИЕ как раз таки предложил я. При чем такое, которое обходит еще кое-какие грабли.
проходящий.Опять не понял. О какой накладочке речь. Не могли бы изъясняться поточнее?
Поточнее – описание проблемы и вопрос звычал следующим образом:
Местами администраторВыполняю запросы к SQL серверу через ODBC при помощи примерно такой конструкции:
nShandle=SQLCONNECT('Taxes',.T.)
tVdok='"'+'select * from fn98'+'"'
nResult=SQLPREPARE(nShandle, &tVdok, "fn98")
IF nResult=1
SQLEXEC(nShandle)
endif
SQLDISCONNECT(nShandle)
Все проходит отлично, однако когда начинаю увеличивать длину запроса (указываю перечень полей для загрузки, использовать условия сортировки, группировки и т.д.) ~>240 символов,
фокс (9) начинает ругаться:
"Команда содержит нераспознанное ключевое слово или фразу", хотя сам запрос однозначно правильный.
Подскажите что за фигня, как побороть или обойти.
Приходиться потом выбрасывать данные, которые не нужны...
Ответ:
проходящий. ЗАЧЕМ тут эти танцы с бубном? ЗАЧЕМ здесь макроподстановка? Уберите ее и все наладится.
Вот именно. Уберите макроподстановку, собирайте строку номальными способами и никакие танцы не понадобятся.
проходящий.кстати, вызывать SQLPREPARE() для однокрано выполняемого батча - бессмыслица

SQLPREPARE() подготавливает SQL-оператор для удаленного выполнения функцией SQLEXEC(). Функция посылает источнику данных SQL-оператор, где он компилируется для более быстрого исполнения.
О.В. Бартеньев (книга о Фоксе)
Кому верить?Обоим. Потому, что я не оспаривал, а уточнил область действия процитрованного утверждения.
ДА, SQLPREPARE() используется для ускорения выполнения. Но только ускорение наступает при одном условии - многократном выполнении подготовленного таким образом батча. Ускорение получается за счет исключения времени подготовки при повторных вызовах. При однократном ускорения не происходит. Сочетание SQLPREPARE() и SQLEXEC() для ОДНОГО выполнения батча
будет даже несколько медленнее одного SQLEXEC() с тем же батчем, так как одна компиляция выполняемого батча тут будет присутствовать в обоих случаях, выполняется всегда компилированный/подготовленны код. Но в первом случае есть еще расходы на вызов дополнительной функции и получение результата ее работы.
Иное дело многократное исполнение. Тогда одни раз компилируется/подготавливается план исполнения и потом несколько раз исполняется этот самый подготовленный план.

Еще вопросы есть?

Местами администраторКогда пойдете в политику?Если вопрос ко мне, то он опять мимо кассы. :) В смысле Вы опять неправильно поняли/интерпретировали мои тут высказывания. Я не собираюсь в политику, мне интереснее решение технических вопросов, а не ... ну Вы меня поняли.
А что вызвало такой вопрос?

Местами администраторТакое ощущение, что специалисты по техническим вопросам могут выкрутиться из любой затруднительной ситуации. :)Иначе бы они не были специалистами, не так ли? :)

Местами администраторУгу, а решение проблемы все таки не Ваше.
Для Вас "предложенное мной" и "мое" - одно и то же?
Разумеется оно не мое лично, не я его придумал, но здесь то его предложил я? Или не я? Или не это, а что-то другое?

Вам еще не надоело добиваться своей "победы"? Неужто так сильно хочется меня задавить? Или это вопрос какого-то "принципа"? Какого? :)