Эпиграф: © В.С. Высоцкий
"Вцепились они в высоту - как в свое,
огонь - минометный и шквальный...
А мы все перли толпой на нее,
Как на буфет вокзальный..."
Igor Korolyov
Hi FoxProHater!
Здесь обычно обмениваются мнениями коллеги, и потому обращение на "ТЫ" не является унизительным, скорее наоборот, но как ВАМ будет угодно...
Дык, я уже дано начал тебе "тыкать", к чему тогда эти твои - "расшаркивания"?
Давай лучше выступать - "по существу" вопроса, а не - цепляясь к формулировкам, выискивая неточности у оппонента и превращая чужие "промахи" в собственные "достижения"...
Igor Korolyov
> скрывать свое знание о его реальных "недостатках".
1) Никто ничего не скрывает. Информация вполне доступна.
От тебя я еще ни разу не сподобился увидеть/узнать что-либо про реальные проблемы FoxPro - одни только сплошные достоинства и ничего более, согласись - как-то не похоже на реальную программную платформу? Скорее - на мечту о "светлом будующем".
Igor Korolyov
2) Вы говорили о недостатках NET? Приводили код на C# который "в 100 строк
содержит 5 глюков"? Так тогда кто из нас относится к вопросу ПРЕДВЗЯТО?
Пока что, на сегодняшний момент, в моих личных более чем 5К строк кода на C# - даже одного несчастного глюка не набралось. Когда "нарою" со временем - может быть напишу об этом в ответ на твое сообщение со списком глюков FoxPro, которые известны тебе.
Igor Korolyov
Если вы вырываете зуб - то следов никаких не остаётся?
...
Нет, вы именно member-объект пытаетесь удалить. Это НЕ ссылка в коллекции.
...
Тогда вам не стоило Page описывать статически
...
Однако повторюсь - ошибка не тут, а в самой первоначальной идее -
пытаться удалить статический member-объект...
Не стоит твердить как заклинание: "динамический", "статический", "мембер", "не ссылка в коллекции", я все это уяснил еще с первого твоего ответа (или считать оппонента "тупым" это - бонтон местных "корифеев"?). Советую обратить внимание на "исследования" Сергея из Киева, который вполне из "вашей песочницы", подтвердил, что в любом другом методе формы, кроме Init - эти все проверки (и на PEMSTAT(...5), и на TYPE("..."), и на VARTYPE(...)) отрабатывают очень четко и "правильно" (т.е. как мне нужно - не пропуская "удаленного статического мембера"), а вот теперь - самое время тебе начать ударяться в рассуждения об "исключительной роли" метода/события Init в подготовке экземпляра класса (хотя, при чем тут Init формы, когда бедный класс-то, из которого "варварски" удаляют "статичных мемберов", должен инстанциироваться Init-ом PageFrame-а, который к тому времени уже давно отработал). Ладно, оставим это на моем плохом понимании синтаксиса определения классов в FoxPro...
Про Visible-ы и ColumnCount-ы - даже ввязываться в дискуссию не хочу, пусть будет считаться как: "баг, описанный в документации это уже не баг, а - "фича"...
Тем более, что делать 1-но свойство одновременно и счетчиком элементов коллекции и признаком автогенерации каких-то внутренних мемберов - это безусловно очень "профессиональный" подход к реализации программной платформы...
Вам еще не доводилось встречать программную среду, в которой при копировании массива - изменяются значения внутри него, или, например, при закрытии стандартного диалога - система генерирует ран-тайм ошибку? НЕТ ЕЩЕ? Да что, вы, ребята? Вы просто - "жизни не видели"...
Добро пожаловать в FoxPro, открываем Command Window:
1.
2.
3.
4.
5.
6.
7.
DIMEN ar1[ 3 ]
ar1[ 1 ]= 1
ar1[ 2 ]= 2
ar1[ 3 ]= 3
o1=creat([custom])
o1.addproperty([items( 3 )],@ar1)
?o1.items( 3 )
?locfile([qwerty]) && закройте потом это окошко нажав на "крест" или ESC
Оно, конечно, в документации про такие "мансы" все-таки написано (куда ж деваться-то, надо же как-то "баги" переводить в "фичи"), только мне уже надоело изучать разделы
Remarks на каждый "пук", о чем и пишу тут с рвением, достойным лучшего применения...
Давай-ка, "коллега", ближе к тому, в чем ты реально мало что понимаешь, зато берешься не только высказывать свои суждения, но и еще и доказывать что-то (просто диву даюсь):
Igor Korolyov
>> - а допустим ли ТАКОЙ синтаксис в SELECT команде? не нужно ли убрать
>> первый строковый литерал?
...
упоминания о том, что RAISERROR можно использовать внутри SELECT я также не обнаружил
...
Если же вы имели в виду что это 2 отдельные команды, то видимо между ними
нужно добавить символ
; - как описано в статье "Specifying Batches"
для ODBC.
Есть очень хорошая поговорка на тему - "на заборе тоже написано...", очень помогает давать советы если сам не знаешь, что и как надо делать. Прочел "написанное" и уже - "специалист".
Igor Korolyov
Так это одна команда, или всё-же Batch из 2-х команд? Я не привык к тому,
что разные команды ничем друг от друга не отделены, и не уверен что ODBC
может корректно обработать такую строку...
> И тут "прокольчик"
Я не случайно оставил свою овер-квотейшн насчет "прокольчика" в твоей...
Т.к. если ты в чем-то "не уверен", к чему-то "не привык" и не можешь отличить "кофе это или чай", то зачем ты вообще пишешь об этом и используешь это в качестве аргументов в дискусси с тем, кто "привык", "знает", "уверен" и отличить в состоянии? Это видимо, тоже - непререкакемый признак "профессионализма".
Отвечаю по существу - да, это 2 разные команды, разделенные символом пробела: первая - SELECT, который возвращает одну запись из одного строкового значения, а вторая - RAISERROR, которая генерирует ран-тайм ошибку на стороне сервера и "хоронит" для FoxPro как результаты исполнения первой, так и свою информацию, которая должна быть показана "клиенту".
Igor Korolyov
нужно как минимум отключить "BatchMode" и воспользоваться SQLMORERESULTS().
Является ли конструкция из одного единственного SELECT и последующего
RAISERROR "многорезультатной" я не могу сказать.
Начну со второго вопроса - является.
Только, SQLMORERESULTS() ничего в данном случае не дает, т.к. не для этого он предназначен, если не веришь мне - спроси у ВладимираМ, он тоже многим советовал "воспользоваться SQLMORERESULTS()" пока его не "ткнули носом"...
Кстати...
FoxProHater
...тот "непроходимый" факт, что FoxPro вплоть до 8-й версии включительно (про 9-ю узнаю точно завтра на работе, но лично я в нее не верю) - не в состоянии адекватно обработать ошибку от ODBC-источника данных, если в запросе (процедуре) присутствуют более 1-го результирующего набора данных (resultset), а после возврата первого возникает ошибка... (условно говоря: "select 'scalar_value' select * from unexisting_table")...
О-СА-Н-Н-Н-Н-НА-А-А-А!!! (руки - горе, ладонями вперед), в 9-й версии эту ошибку таки "побороли", не прошло и 10-ти лет существования VFP-6-7-8, как "добрые" разработчики разглядели "под самым носом" то, что не имеет прямого отношения к DBF-кам...
А также, например, огромное спасибо тому "добряку", который ажно в 8-й версии "догадался" ввести системную переменную _PAGETOTAL, а то, ведь людям нормальным до этого делать было больше, ну абсолютно - нечего, кроме как "изеб....ся" разными способами для того, чтобы получить в многостраничном отчете надпись: "стр. Х из У" (особенно мне понравился 1 способ из wiki - выводить PREVIEW отчета в специально опеределенное окно, "задвинутое" за границы видимой области экрана, просто "пестня", хорошо мозги "поворачивает" в сторону "любви" и "преданности" FoxPro).
Igor Korolyov
> например, тот же ADODB.Recordset
Вообще-то ADODB обычно работает не с ODBC драйвером, а непосредственно с Ole DB провайдером.
Угу (все как обычно, источник "профессионализма" - агенство ОБС), попробуй набрать в командном окне FoxPro (скажешь мне потом, что получил, и что это значит?):
1.
c1 = creat([adodb.connection])
?c1.Provider
Igor Korolyov
О ком это? ODBC такая-же сторонняя система для VFP как и OLE DB и ADO.
"Родное" для него это прямой доступ к dbf и ничего более.
Угу, только фунции типа SQLXXXX() даже не спрашивают о том, какой "драйвер" или "провайдер" будем использовать? ODBC, милай, ODBC... и ничего другого не выберешь...
Igor Korolyov
...ибо для меня ошибка - она и есть ошибка - независимо
от того существует она в VFP, в .NET или в любой другой программе. И почему
ошибки в NET это "ничего страшного" а ошибки в VFP это причина называть его всякими обидными словами - я не понимаю.
Еще раз повторю свое личное мнение - ошибки в .NET это исключения (почти каламбур получился, насчет Exception), а ошибки в FoxPro - это ПРАВИЛО (именно так, со всех заглавных букв). Даже если они "некритические (когда способ обхода известен и не представляет никакой проблемы)", то все равно - отнимают кучу такого нужного всем нам времени, которое можно (и нужно) использовать не на поиски "способов обхода", а на более полезные/приятные занятия.
З.Ы. я вот, смотрю, что дискуссия плавно перетекла в русло обсуждения "движков" SQL... Ребяты, ей-БГ, не суйтесь, пжлст, на поле серверов БД со своим "тряпичным мячом", разорвут... Вспомните, например, еще такое "преимущество", как - "интерпретируемость готового кода"... может быть, хоть это кому-нибудь счаз будет "интересно"/"полезно"? Хотя, даже на этом "поле" .NET уже впереди - System.CodeDom.Compiler.CodeDomProvider это вам не "макроподстановка" через "оператор" - &...
