Select SQL - to Aleksey Tsingauz [MSFT]... | |
---|---|
piva Автор Сообщений: 18655 Откуда: Курган Дата регистрации: 24.03.2004 |
Если в vfp9 сделали коллекции доступными для ListBoх - вдруг в релизе прикрутят к grid - по почему- бы не сделать выборку в коллекцию ?
А что - классно было бы Select ... into collection oMyCollection |
Re: Select SQL - to Aleksey Tsingauz [MSFT]... | |
---|---|
Syberex Сообщений: 1432 Откуда: Кострома Дата регистрации: 19.01.2004 |
А какая, в данном случае, будет разница между массивом и коллекцией?
------------------ |
Re: Select SQL - to Aleksey Tsingauz [MSFT]... | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
В массиве доступ только по индексу, а в коллекции - по индексу или
ключу. Правда не совсем ясно что же будут представлять собой элементы колекции - то-ли коллекции полей (индекс - имя поля), то-ли такой-же Empty-объект что и по SCATTER NAME получается... Однако IMHO это не самое крутое - самое крутое было-бы реализовать Grid вообще без привязки к источнику данных - чтоб он запрашивал данные через какой-то свой Event типа GetCell, или GetRow... Ну ессно "предполагаемое число строк" надо задавать явно - зато потом рули себе динамически загрузкой данных - ну т.е. примерно как делает сам Grid объект, или банальнейший BROWSE (он же качает только те записи что надо для "заполнения видимой области")... Да, мечты, мечты... Ведь даже Объектного меню не сделали, хотя AFAIK в Top 10 вишей оно было наряду с ОО-репортером... P.S. За прошлую неделю в FIDO7.RU.VISUAL.FOXPRO описали 2 явных бага (индекс UPPER(символьное_русское_поле) по таблице в 866-й CP и несохранение пользовательских свойств для субклассированных колонок в гриде) которые присуствуют в VFP9 Public Beta по наследству от VFP8 и более ранних. И 1 неплохой виш (про позицию курсора в текстбоксе лимитированном маской или MaxLength - не перед последним введённым символом, а после него). Правда я не уверен что эти уважаемые (и очевидно очень занятые) господа найдут время оформить багрепорт Aleksey, вы видели эти сообщения? Если нет, то вот их MSGID - по ним их просто найти... Message-ID: <ccg3u1$23nr$1@ddt.demos.su> Message-ID: <ccimk9$1mo$1@host.talk.ru> Message-ID: <''.phorum_html_encode('1565867865.20040707093122@tsrv.ru').''> ------------------ WBR, Igor |
Re: Select SQL - to Aleksey Tsingauz [MSFT]... | |
---|---|
Aleksey Tsingauz [MSFT] |
Цитата: Здравствуйте, Вадим! В настоящее время, мы не планируем добавит поддержку Collection в Grid. Aleksey Tsingauz Visual FoxPro Dev Team |
Re: Select SQL - to Aleksey Tsingauz [MSFT]... | |
---|---|
Aleksey Tsingauz [MSFT] |
Цитата: Здравствуйте, Игорь! Понятия не имею как использовать эти MSGID для поиска сообщений. Просветите, пожалуйста. Я предпочитаю читать FIDO7.RU.VISUAL.FOXPRO через Outlook Express, так что если бы вы включили Subject и дату, то было бы хорошо. Пока что из этих трех я видел только одно - про UPPER. К сожалению, сообщение не содержит ни репро кода, ни описания как выглядит "белиберда" и "полная ерунда", ни описание ожидаемого результата. Я так понимаю, что вы знаете о чем идет речь. Пожалуйста, поделитесь. Aleksey Tsingauz Visual FoxPro Dev Team |
Re: Select SQL - to Aleksey Tsingauz [MSFT]... | |
---|---|
piva Автор Сообщений: 18655 Откуда: Курган Дата регистрации: 24.03.2004 |
Здравствуйте Алексей
Про Collection для Grid, понятно, а Collection для Select SQL, видимо тоже не будет ? |
Re: Select SQL - to Aleksey Tsingauz [MSFT]... | |
---|---|
Aleksey Tsingauz [MSFT] |
Цитата: Вадим, намёк вы поняли правильно. Изменения такого рода имеет низкий приоритет потому что всегда можно написать SCAN цикл и заполнить Collection именно так как вы хотите. Ведь представление результата в виде Collection не совсем однозначно: Создавать Collection с ключем или без? Если с ключем, то что выступает в роли ключа? Текстовое представление номера записи или что-то еще? Что выступает в роли элемента Collection? Другая Collection, массив, SCATTER объект? Делать что-то одно, многие остануться недовольны - не сделали так как им надо. Делать все - надо много времени на разработку и еще больше на тестирование. Aleksey Tsingauz Visual FoxPro Dev Team |
Re: Select SQL - to Aleksey Tsingauz [MSFT]... | |
---|---|
piva Автор Сообщений: 18655 Откуда: Курган Дата регистрации: 24.03.2004 |
Ну не будет - так не будет. Чего-нибудь сами придумаем.
Спасибо |
Re: Select SQL - to Aleksey Tsingauz [MSFT]... | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Набрать в любом понимающем URL-ы окне (IE, Explorer, да хоть и Run адрес
следующего вида: news://ddt.demos.su/ccg3u1$23nr$1@ddt.demos.su Где вместо доменного адреса (не тот что часть MSGID!) ddt.demos.su можно указать свой гейт (только чтоб он не требовал авторизацию). Или пойти на Google и там в расширенном групповом поиске искать по идентификатору - получится URL вида: [url]http://www.google.com/groups?ie=UTF-8&as_umsgid=ccg3u1%2423nr%''.phorum_html_encode('241@ddt.demos.su').''[/url] Замечу только что "нехорошие символы" в MSGID будут перекодированы в соответствии со схемой URLEncode (% + hex код символа). Цитата:Я тоже, (надстройкой к OE стоит Fidolook) но к сожалению там нету поиска по MSGID, надеюсь что только пока Цитата:Уточняю:
Кстати там и к "без UPPER" есть свои вопросы. В смысле MACHINE как-то не "машинит"... Т.е. пытается не по ASCII кодам сортировать, а по каким-то перекодированным кодам. ------------------ WBR, Igor |
Re: Select SQL - to Aleksey Tsingauz [MSFT]... | |
---|---|
Aleksey Tsingauz [MSFT] |
Цитата: Здравствуйте, Игорь! Да вроде все тут "машинит" и результат вполне объясним. При построении идекса нужно учитывать следующую деталь. Когда индексное выражение вычисляется, значения полей читаются с диска как есть, без трансляции в текущую кодовою страницу. А вот многие функции оперируют по разному, в зависимости от текущей кодовой страницы. UPPER один из примеров такой функции. Если текущая кодовая страница 1251 а кодовая страница таблицы 866, то к букве "а" в кодировке 866 UPPER применит кодовую страницу 1251. Естественно, буквы "А" в кодировке 866 не получится. Если планируется строить индексы или модифицировать данные под разными текущими кодовыми страницами, то индексное выражение должно быть инвариантно отностельно текущей кодовой страницы. Например, в данном случае можно использовать:
Aleksey Tsingauz Visual FoxPro Dev Team |
Re: Select SQL - to Aleksey Tsingauz [MSFT]... | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
1) Полагаться на RUSSIAN я бы не стал по простой причине:
SET COLLATE TO "RUSSIAN" ? CHR(1) = CHR(2) ? BINTOC(1) = BINTOC(2) Соответственно и для таблиц с составными индексными ключами (например "агрегатов" реализующих связи много-ко-многим). Результат JOIN скажем будет неверный (а "сцеплять" иначе 2 INTEGER-поля IMHO неразумно). Постоянно дёргать же COLLATE тоже не есть хорошо, да и Rushmore не поймёт меня... 2) По поводу "не машинит": Убираем из примера UPPER (делаем тривиальный индекс по полю) и наблюдаем что например в самом начале идёт так (по кодам символов): 187 171 182 167 32 33Что никак не соответствует моему пониманию MACHINE. Меняем в примере CODEPAGE=1251 и наблюдаем ожидаемое поведение - упорядочено именно по кодам. Я уж не знаю на каком этапе создания индекса происходит конвертация, но она явно происходит (причём даже без всяких UPPER). Причём баг явно обнаруживается и в VFP8SP1 (возможно и в более старых). 3) Снова вернёмся к COLLATE "RUSSIAN" - в вышеуказанном примере делаем индекс INDEX ON UPPER(cName) TAG cName COLLATE 'RUSSIAN' И наблюдаем... Да, опять полная неразбериха. Где буковка я, и где ш [i][small][color=Gray]Отредактировано (17.07.04 03:52) ------------------ WBR, Igor |
Re: Select SQL - to Aleksey Tsingauz [MSFT]... | |
---|---|
Aleksey Tsingauz [MSFT] |
Здравствуйте, Игорь!
Цитата: Не подходит, так не подходит, вам виднее для чего вы строите индекс. Я посчитал, что цель использования UPPER - добится сортировки нечувствительной к регистру букв. В этом случае, использование "Russian" collate может быть приемлемо. Цитата: Да никакой это не баг, а ожидаемый результат. Давайте пойдем по шагам. 1) В VFP с CPCURRENT()==1251 запускаем следующий код:
2) Чтобы в этом убедится, запускаем вот такой SELECT:
3) Строим индекс:
4) Проверяем сортированную последовательность:
5) Заключительная проверка. Загружаем VFP c CPCURRENT()==866 и убеждаемся, что индекс действительно отсортировал cName по возрастанию кодов (COLLATE "MACHINE"). Удаляем индекс и строим заново. Результат - получаем ту же самую последовательность. Цитата:Я уже объяснял в чем специфика использования функции UPPER. Oна всегда считает, что входные данные закодированы с помощью CPCURRENT(). Вы получаете то, что должны получить. Это все равно, что умножать 2*2 и ожидать 5. Aleksey Tsingauz Visual FoxPro Dev Team |
Re: Select SQL - to Aleksey Tsingauz [MSFT]... | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Ну я примерно про то и говорил - данные "отображаемые" несоответствуют
данным "хранящимся". То что это происходит не в цепи таблица-индекс а в цепи таблица-отображение, сути не меняет (для меня). Хотя как-то отразить эту особенность (про работу с таблицами в "неродных" кодировках) в хелпе или какой статье KB наверное стоит, ну чтоб по крайней мере потом не было вопросов/претензий что "не предупредили"... ------------------ WBR, Igor |
Re: Select SQL - to Aleksey Tsingauz [MSFT]... | |
---|---|
Aleksey Tsingauz [MSFT] |
Здравствуйте, Игорь!
Цитата: А для нас это многое меняет. В принципе, в этом то и весь смысл назначения определенной кодовой страницы для таблиц. С какой целью вы создавали таблицу в кодировке 866 и не указали NOCPTRANS флаг для поля? Цитата:Вопросы - пожалуйста. А вот претензий по поводу "не предупредили" быть не должно. В документации достаточно много информации по кодовым страницам. Вот одна цитата: *------- Understanding Code Pages in Visual FoxPro Visual FoxPro displays data using one code page. By default, this is the current code page used by Windows. However, you can override the Windows code page by specifying an alternative code page in your configuration file (you must specify a valid code page). Tables in Visual FoxPro are tagged with the code page that was in use when the table was created. When you use the table, Visual FoxPro checks the code page for the table against the current code page. If they match, Visual FoxPro displays the data as is. If there is no code page for the table (for example, the table was created in an earlier version of FoxPro), Visual FoxPro prompts you for a code page and then marks the file with it. If the table code page does not match the system code page, Visual FoxPro attempts to translate characters from the table code page into the current one. For example, if you're using Visual FoxPro and the current system code page is the English code page, the character ü is represented by ANSI value 252. If the code page for the table represents the ü character as ANSI value 219, Visual FoxPro translates all instances of ANSI value 219 into ANSI 252 so that they display properly. *------- Aleksey Tsingauz Visual FoxPro Dev Team |
Re: Select SQL - to Aleksey Tsingauz [MSFT]... | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
1) Я ничего не создавал. Это вообще не моя проблема была (хотя я и пользуюсь
таблицами созданными в FPD/Clipper т.е. 866 CP, но у них нету индексных тегов, да и пользуюсь я ими лишь для "загрузки" в "правильные" таблицы - т.е. CP 1251) 2) Мало, мало того что сказано в процитированном. Надо и про возможные "проблемы" с индексами написать, и вообще про работу с таблицами в разных CP в пределах одной сессии... Не обязательно в документации, возможно стоит в KB статью написать - для тех кому это реально надо (в Штатах ясное дело никому до того дела нету). 3) Ну и вообще я давно уже говорил что полного порядка до перевода фокса на Unicode нет и быть не может Пока фокс работает в одной кодовой странице единовременно (и для её смены нужно вообще полностью перегружать среду!), никакой реальной многоязыковости добиться нельзя. P.S. Я прекрасно понимаю все сложности связанные с переводом фокса на Unicode, и понимаю весьма узкий рынок где это реально надо. Потому и не говорю что это "первоочередное"... Но в перспективе, наверное стоит подумать и про такое решение... ------------------ WBR, Igor |
Re: Select SQL - to Aleksey Tsingauz [MSFT]... | |
---|---|
Aleksey Tsingauz [MSFT] |
Здравствуйте, Игорь!
Цитата:Мой вопрос не подразумевал под собой того, что сам факт создания такой таблицы - ошибка или плохой выбор. Скорее, он должен был подчеркнуть, что есть в этом что-то особенное. Что-то, что нельзя получить создав таблицу с кодовой страницей 1251 - хранение текста в кодовой странице 866. Соответственно, это интуитивно понятно, что данные будут транслированы, чудес то ведь не бывает. Цитата:Я не буду спорить о том нужна или нет КВ статья на эту тему. Я просто еще раз подчеркну, что в документации есть целый раздел посвященный подобного рода проблемам "Creating International Applications", приведенная цитата - это всего лишь несколько абзацев из него. У меня ушло всего две минуты на то, чтобы ее найти. Вы заметили, что цитата как раз объясняет разницу между тем, что вы "видите" и тем, что реально хранится в таблице? Мало того, что вы не потрудились сделать это сами, прежде чем списывать все на отсутствие документации, дак вы еще продолжаете судить о документации по одной этой цитате. Как-то быстро вы делаете свои заключения, вам не кажется? Признаюсь, я весь тот раздел не читал, очень вероятно, что какие-то детали там не отражены или отражены не так, как хотелось бы. Я так же не проверял есть ли существующая КВ статься на эту тему и совсем не удивлюсь если есть. Короче, при таком вашем подходе, каковы шансы, что новая КВ статья что-то изменит? Aleksey Tsingauz Visual FoxPro Dev Team |
Re: Select SQL - to Aleksey Tsingauz [MSFT]... | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Ну зачем же так плохо думать Я прочитал внимательно весь раздел, но вот
из него как раз и не вытекает описанное поведение. А по косвенным намёкам оттуда понять что происходит очень сложно. Уже одно то что одновременно два разных человека спрашивают в разных местах про "это" говорит в пользу моего мнения о неясности изложения вопроса. То что индекс строится по неперекодированным, а показ идёт в перекодированном... Я бы без вашего описания вряд-ли догадался в чём тут дело... ------------------ WBR, Igor |
Re: Select SQL - to Aleksey Tsingauz [MSFT]... | |
---|---|
Aleksey Tsingauz [MSFT] |
Здравствуйте, Игорь!
Цитата:Примите мои извинения если я неправильно интерпретировал ваше сообщение. Цитата:Мы постараемся ликвидировать этот пробел в документации по VFP9. Aleksey Tsingauz Visual FoxPro Dev Team |
Re: Select SQL - to Aleksey Tsingauz [MSFT]... | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
ОК
Тогда с вашего позволения ещё одно тонкое место в документации - использование CursorAdapter с XML источниками данных - процедура генерации XMLUpdategram-мы средствами самого CA (т.е. через CA.UpdateGram) - то что надо в InsertCmd (ну и.т.д) прописать вызов фоксовой функции (лучше метода, ещё лучше метода данного объекта CA) и тогда изнутри этого метода CA.UpdateGram вернёт то что надо... В общем пока я в инете не нашёл статью с примером (к большому сожалению он сейчас где-то затерялся и автора я назвать затрудняюсь... Но там по всем видам источников данных вроде как примеры и неплохие разъяснения были - да источник англоязычный) - то приручить это свойство я никак не мог Возможно стоит договорится с авторами и включить эту статью в документацию? Ибо по CA Walkthrough довольно таки схематичный (и с ADO источниками для СА - я пока сам не работал, но по "просто прочтению" не совсем всё понятно и прозрачно) Как только найду линк, обязательно сообщу... ------------------ WBR, Igor |
© 2000-2024 Fox Club  |