ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / FoxPro, Visual FoxPro [игнор отключен] [закрыт для гостей] / (VFP 9.0) Первое крупное неудобство в VFP 9.0
19 сообщений из 19, страница 1 из 1
(VFP 9.0) Первое крупное неудобство в VFP 9.0
    #33172280
Sergey Ch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergey Ch
Участник
Если у Вас таблицы от старой версии FoxPro (например, DOS), то в VFP 9.0 не будет работать оптимизация запросов как это было в 8.0 . Это, увы, не BUG... Это сделано умышленно. Оптимизация будет только работать, если кодовая таблица среды программы и таблицы совпадает....

То есть там, где у Вас все "летало", при перехроде на версию 9.0 может наступить сильная деградация скорости выполнения запроса... Лечится все это простым копированием таблиц в среде 9.0 по умолчанию вместе с индексом в новую таблицу (когда это возможно)...

Код: plaintext
COPY TO Table1 with CDX

Хотя, как у нас любят говорить - "возможны варианты"...

Всего Вам доброго, и надеюсь, что мое сообщение Вас не сильно расстроит...
...
Рейтинг: 0 / 0
18.07.2005, 21:09:34
| Ответить | Цитировать | Написать  
(VFP 9.0) Первое крупное неудобство в VFP 9.0
    #33172362
luser
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
luser
Участник
Угу, уже попался. "И так и сяк попой об косяк" - поставил 8 - работает 9 даже запрос типа select * from lala INTO TABLE ..., а таблица вся нужна не хочет делать нормально. Пытаюсь потом таблицу такую открыть - говорит , пошел накуй. А меньшего обема выборки открытвает. Вот зараза. Вернулся на 8. Все летает.
...
Рейтинг: 0 / 0
18.07.2005, 22:41:31
| Ответить | Цитировать | Написать  
(VFP 9.0) Первое крупное неудобство в VFP 9.0
    #33172397
Гулин Федор
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гулин Федор
Участник
да - это касается СТРОКОВЫХ индексов - этой действительно фича 9 -
А.Цингауз (Foxteam) отвечал на этот ? на foxclub
ps ну значит будем отбирать по дате или числовым полям :))
или перебивать таблицы в нужную (у меня 1251) кодировку
...
Рейтинг: 0 / 0
19.07.2005, 00:15:21
| Ответить | Цитировать | Написать  
(VFP 9.0) Первое крупное неудобство в VFP 9.0
    #33172425
Igor Korolyov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Igor Korolyov
Участник
Hi Sergey!

Если учесть, что ДО VFP9 "оптимизированная" работа с такой DBF могла вызвать получение некорректного результата - то мне кажется что это не неудобство, а совершенно правильно устранённая ошибка. Вообще работа с "неродными" CP всегда вызывала массу проблем...

2 luser
В VFP9 есть ошибка (видимо в SP1 исправят), когда при копировании из таблицы с неродной CP memo-поля не перекодируются, но чтобы новая таблица после такого копирования становилась испорченной - первый раз слышу. Естественно что более ранние версии не всегда смогут открыть таблицу, созданную в VFP9 - если в ней есть "новые" var* поля например... Однако это не есть ошибка.

Также разработчики говорят, что ужесточили контроль за целостностью в плане memo-полей - "слегка испорченные" таблицы, которые открывались в VFP8 уже будут вызывать ошибку в VFP9. Однако это опять таки нельзя считать ошибкой - это специально сделанное улучшение - работа с "порченной" таблицей обычно в конце концов приводит либо к зависанию, либо к c005...

Posted via ActualForum NNTP Server 1.2
...
Рейтинг: 0 / 0
19.07.2005, 01:14:50
| Ответить | Цитировать | Написать  
(VFP 9.0) Первое крупное неудобство в VFP 9.0
    #33172570
Sergey Ch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergey Ch
Участник
Ну почему, 866 и 1251, 437 и 1252 etc... Вроде бы как должны быть родными ... Насчет FoxClub не знаю, но ответ на свой вопрос о деградации скорости работы VFP 9.0 я нашел на UT, где отвечал Ken Levy что это features... За мою практику у меня всего пару раз были проблемы в связи использованием не родных индексов, но они легко обходились...

Пока тоже вернулся на 8.0 в текущем проекте, может как обычно Большой Брат подумает и все исправит в SP1...
...
Рейтинг: 0 / 0
19.07.2005, 09:20:56
| Ответить | Цитировать | Написать  
(VFP 9.0) Первое крупное неудобство в VFP 9.0
    #33173905
luser
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
luser
Участник
Да я клянусь. тащу таблицу больше полтора гигов. (Дурацкая затея но нужно именно так), результат выборки падает и на 6 и на 7 и на 9. А 8 открывает Фантастика!!!
...
Рейтинг: 0 / 0
19.07.2005, 15:44:34
| Ответить | Цитировать | Написать  
(VFP 9.0) Первое крупное неудобство в VFP 9.0
    #33174795
Igor Korolyov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Igor Korolyov
Участник
Hi Sergey!

Ты глубоко заблуждаешься, если считаешь что между 866 и 1251 существует ВЗАИМНО ОДНОЗНАЧНОЕ соответствие. Думаю что и с другими языками ситуация точно такая-же. Проверь если интересно через банальнейшие циклы с CPCONVERT.
Про проблемы с UPPER() в FPD индексе подробно разжёвывалось на foxclub.ru - с участием Алексея Цингауза - думаю что корни там одни и те-же.
Так что 99% за то что никакого возврата не будет.

2 luser

Ничего не могу сказать, не видя воочию такого чуда.

Posted via ActualForum NNTP Server 1.2
...
Рейтинг: 0 / 0
20.07.2005, 00:04:16
| Ответить | Цитировать | Написать  
(VFP 9.0) Первое крупное неудобство в VFP 9.0
    #33174811
luser
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
luser
Участник
Могу в гости пригласить. Сам увидишь.
...
Рейтинг: 0 / 0
20.07.2005, 00:25:58
| Ответить | Цитировать | Написать  
(VFP 9.0) Первое крупное неудобство в VFP 9.0
    #33175137
Sergey Ch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergey Ch
Участник
Igor KorolyovТы глубоко заблуждаешься, если считаешь что между 866 и 1251 существует ВЗАИМНО ОДНОЗНАЧНОЕ соответствие...
Согласен, на низком уровне они различны...

Но для меня как программиста баз данных (и соответственно для среды исполнения это должно однозначно одинаково интерпретироваться, так-как язык один, хотя надо сюда-жк и Macintosh добавить. В VFP 8.0 сделано и работает все правильно (или может я чего не замечал ))
...
Рейтинг: 0 / 0
20.07.2005, 10:35:54
| Ответить | Цитировать | Написать  
(VFP 9.0) Первое крупное неудобство в VFP 9.0
    #33177052
Igor Korolyov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Igor Korolyov
Участник
Hi Sergey!

> Но для меня как программиста баз данных...

Наиважнейшим должна быть КОРРЕКТНОСТЬ информации а не скорость выполнения.
Если гнаться за скоростью - просто печатай юзеру своп виндовый :) Галиматья
конечно полная, зато очень быстро :)

> В VFP 8.0 сделано и работает все правильно (или может я чего не
> амечал ))

Не заметил видимо :)

Запусти в FPD программку:

CREATE TABLE tFPD (nID N(4), cname C(10))
FOR ln1 = 0 TO 255
INSERT INTO tFPD (nID, cName) VALUES (m.ln1, CHR(m.ln1))
ENDFOR
INDEX ON cName TAG cName

Затем в VFP8 запусти следующий тест:

SYS(3054, 12)
CREATE TABLE tVFP (nID N(4), cname C(10))
FOR ln1 = 0 TO 255
INSERT INTO tVFP (nID, cName) VALUES (m.ln1, CHR(m.ln1))
ENDFOR
SELECT * FROM tFPD, tVFP WHERE tVFP.cName = tFPD.cName
* Полюбуйся на полученный результат 205 записей вместо 256.
* Зато используется индекс.

Теперь выполни тот же запрос в VFP9 получим ОТСУТСТВИЕ оптимизации (точнее
temp индекс будет создан) зато корректный результат.

Или чуть менее очевидный пример (он учитывает то что при конвертации между
866-1251 часть символов теряется).

SELECT * FROM tFPD t1, tFPD t2 WHERE t1.cName = t2.cName

* В VFP8 имеем всего 247 записей, тогда как в VFP9 - уже 970 записей
* корректно соединились в декартово произведение те записи
* которые при конвертации получили одинаковые символьные значения

* Или ещё интереснее - добавим индекс к VFP таблице
INDEX ON cName TAG cNameVFP
* И выполним в VFP8 последовательно 2 ИДЕНТИЧНЫХ по сути запроса:
SELECT * FROM tVFP, tFPD WHERE tVFP.cname = tFPD.cname
* 205 записей
SELECT * FROM tFPD, tVFP WHERE tVFP.cname = tFPD.cname
* 256 записей
* Чётко видно что использование FPD индекса для оптимизации привело к
некорректным результатам

Я даже не заикаюсь о проблемах с UPPER(char) индексами по таблице в
CPDBF=866, особенно если их ИЗМЕНЯТЬ в VFP среде, или не дай бог там
создать/пересоздать индекс...

Posted via ActualForum NNTP Server 1.2
...
Рейтинг: 0 / 0
21.07.2005, 03:52:07
| Ответить | Цитировать | Написать  
(VFP 9.0) Первое крупное неудобство в VFP 9.0
    #33177118
Фотография Владимир СА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владимир СА
Участник
Hi, Igor Korolyov !
Извиняюсь, что вступаю в чужие дебаты. Вы оба конечно ГУРУ.
Но у меня результаты такие:
1. Создал таблицу в FPD26
Код: plaintext
1.
2.
3.
4.
CREATE TABLE tFPD (nID N( 4 ), cname C( 10 ))
FOR ln1 =  0  TO  255 
INSERT INTO tFPD (nID, cName) VALUES (m.ln1, CHR(m.ln1))
ENDFOR
INDEX ON cName TAG cName
2. Создал таблицу в VFP80SP1 ver 08.00.0000.3117
Код: plaintext
1.
2.
3.
CREATE TABLE tVFP (nID N( 4 ), cname C( 10 ))
FOR ln1 =  0  TO  255 
  INSERT INTO tVFP (nID, cName) VALUES (m.ln1, CHR(m.ln1))
ENDFOR
3. Запускаю программу в VFP80
Код: plaintext
1.
2.
3.
4.
SYS( 3054 ,  12 )
USE TVFP IN  0 
USE TFPD IN  0 
SELECT * FROM tFPD, tVFP WHERE tVFP.cName = tFPD.cName
?_Tally
* Результат: Joining table TVFP and table TFPD using index tag Cname
* _Tally = 256
4. Запускаю ту же программу что и п.3 в VFP90 ver 09.00.0000.2412
* Результат: Joining table TVFD and table TVFP using TEMP INDEX
* _Tally = 256
5. Теперь с другим SELECTом. Составлена программа:
Код: plaintext
1.
2.
3.
SYS( 3054 ,  12 )
USE TFPD IN  0 
SELECT * FROM tFPD t1, tFPD t2 WHERE t1.cName = t2.cName
?_Tally
При запуске ее в VFP80 результат:
Joining table T1 and table T2 using index tag Cname
* _Tally = 256
При запуске ее в VFP90 результат:
Joining table T1 and table T2 using TEMP INDEX
* _Tally = 970
6. Добавляем индекс к VFP таблице
Код: plaintext
INDEX ON cName TAG cNameVFP
Создадим програмку
Код: plaintext
1.
2.
3.
4.
5.
6.
SYS( 3054 ,  12 )
USE TVFP IN  0 
USE TFPD IN  0 
SELECT * FROM tVFP, tFPD WHERE tVFP.cname = tFPD.cname
?_Tally
SELECT * FROM tFPD, tVFP WHERE tVFP.cname = tFPD.cname
?_Tally
Результат в VFP80:
* SELECT * FROM tVFP, tFPD WHERE tVFP.cname = tFPD.cname
* Joining table TVFP and table TFPD using index tag Cname
* _Tally = 256
*-----------
* SELECT * FROM tFPD, tVFP WHERE tVFP.cname = tFPD.cname
* Joining table TFPD and table TVFP using index tag Cnamevfp
* _Tally = 256
*-----------
Результат в VFP90:
* SELECT * FROM tVFP, tFPD WHERE tVFP.cname = tFPD.cname
* Joining table TFPD and table TVFP using index tag Cnamevfp
* _Tally = 256
*-----------
* SELECT * FROM tFPD, tVFP WHERE tVFP.cname = tFPD.cname
* Joining table TFPD and table TVFP using index tag Cnamevfp
* _Tally = 256
*-----------
У меня вот такие результаты...
...
Рейтинг: 0 / 0
21.07.2005, 08:18:02
| Ответить | Цитировать | Написать  
(VFP 9.0) Первое крупное неудобство в VFP 9.0
    #33177353
Sergey Ch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergey Ch
Участник
To: Igor Korolyov & Владимир СА

Спасибо за проведенное небольшое исследование. К сожалению, в данный момент у меня на машине нет FPD 2.6 a (RUS) так что не могу сразу повторить Ваш пример.

Если у Вас будет возможность, то нельзя ли посмотреть установку в Ваших примерах
Код: plaintext
SET COLLATE TO
И можно ли првести эксперименты для
Код: plaintext
1.
2.
SET COLLATE TO 'RUSSIAN' 
and
SET COLLATE TO 'MACHINE'
И появится ли разница? Кстати, какой параметр CODEPAGE =??? в config.fp and config.fpw?

Просто я подумал еще немного и пришел к выводу, что в большинстве своих программ я использую индексы по числовым выражениям и датам, а если использую символьные, то как правило SYS(2015) (а английский алфавит имеет одни и те-же значения). За редким исключением поиска по именам, фамилиям, наименованию товара...
...
Рейтинг: 0 / 0
21.07.2005, 10:25:58
| Ответить | Цитировать | Написать  
(VFP 9.0) Первое крупное неудобство в VFP 9.0
    #33177613
Фотография Владимир СА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владимир СА
Участник
Hi, Sergey Ch !
В приведенном небольшом мною ВЫШЕ исследовании принимались:
в FPD26:
?SET('COLLATE') = 'MACHINE'
в CONFIG.FP неоказалось строки
CODEPAGE =
при первом открытии таблицы TFPD в VFP пришлось указать кодовую страницу 866.
В VFP80 и VFP90:
?SET('COLLATE') = 'MACHINE'
в CONFIG.FPW
CODEPAGE = 1251
...
Рейтинг: 0 / 0
21.07.2005, 12:03:36
| Ответить | Цитировать | Написать  
(VFP 9.0) Первое крупное неудобство в VFP 9.0
    #33177750
Sergey Ch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergey Ch
Участник
Владимир САHi, Sergey Ch !
В приведенном небольшом мною ВЫШЕ исследовании принимались:
в FPD26:
?SET('COLLATE') = 'MACHINE'
в CONFIG.FP неоказалось строки
CODEPAGE =
при первом открытии таблицы TFPD в VFP пришлось указать кодовую страницу 866.
В VFP80 и VFP90:
?SET('COLLATE') = 'MACHINE'
в CONFIG.FPW
CODEPAGE = 1251
Понятно... А пробовали делать с RUSSIAN Collate? (хотя мне кажется, результат будет аналогичным)...
...
Рейтинг: 0 / 0
21.07.2005, 12:45:26
| Ответить | Цитировать | Написать  
(VFP 9.0) Первое крупное неудобство в VFP 9.0
    #33177833
Фотография ВладимирМ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВладимирМ
Участник
2 Владимир СА

При открытии FPD 2.6 что показывает команда

?CPCURRENT()

Поскольку Вы не использовали CONFIG.FP, то есть подозрение, что DOS таблица была заполнена в CP 1251. Сейчас нет под рукой FPD...
...
Рейтинг: 0 / 0
21.07.2005, 13:08:24
| Ответить | Цитировать | Написать  
(VFP 9.0) Первое крупное неудобство в VFP 9.0
    #33177839
Фотография Владимир СА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владимир СА
Участник
Sergey ChПонятно... А пробовали делать с RUSSIAN Collate? (хотя мне кажется, результат будет аналогичным)...
Результаты обескураживают!!!

Исследование №2

В Config.fp для FPD26
CODEPAGE=866
COLLATE=RUSSIAN

В Config.fpw для VFP80 и VFP90
CODEPAGE=1251 && это уже было
COLLATE=RUSSIAN

Как и в предыдущем исследовании
1. Создал таблицу tFPD в FPD26
2. Создал таблицу tVFP в VFP80
3. Запускаю программу в VFP80
* Результат: Joining table TVFP and table TFPD using index tag Cname
* _Tally = 1385
4. Запускаю ту же программу что и п.3 в VFP90
* Результат: Joining table TVFD and table TVFP using TEMP INDEX
* _Tally = 1502
5. Теперь с другим SELECTом.
При запуске ее в VFP80 результат:
Joining table T1 and table T2 using index tag Cname
* _Tally = 1427
При запуске ее в VFP90 результат:
Joining table T1 and table T2 using TEMP INDEX
* _Tally = 2150
6. Добавляем индекс
Результат в VFP80:
* SELECT * FROM tVFP, tFPD WHERE tVFP.cname = tFPD.cname
* Joining table TVFP and table TFPD using index tag Cname
* _Tally = 1358
*-----------
* SELECT * FROM tFPD, tVFP WHERE tVFP.cname = tFPD.cname
* Joining table TFPD and table TVFP using index tag Cnamevfp
* _Tally = 1502
*-----------
Результат в VFP90:
* SELECT * FROM tVFP, tFPD WHERE tVFP.cname = tFPD.cname
* Joining table TFPD and table TVFP using index tag Cnamevfp
* _Tally = 1502
*-----------
* SELECT * FROM tFPD, tVFP WHERE tVFP.cname = tFPD.cname
* Joining table TFPD and table TVFP using index tag Cnamevfp
* _Tally = 1502
*-----------
У меня вот так!!!
...
Рейтинг: 0 / 0
21.07.2005, 13:09:26
| Ответить | Цитировать | Написать  
(VFP 9.0) Первое крупное неудобство в VFP 9.0
    #33177937
Фотография Владимир СА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владимир СА
Участник
ВладимирМ
При открытии FPD 2.6 что показывает команда
?CPCURRENT()
Поскольку Вы не использовали CONFIG.FP, то есть подозрение, что DOS таблица была заполнена в CP 1251. Сейчас нет под рукой FPD...
?CPCURRENT() = 0
...
Рейтинг: 0 / 0
21.07.2005, 13:36:36
| Ответить | Цитировать | Написать  
(VFP 9.0) Первое крупное неудобство в VFP 9.0
    #33179207
Igor Korolyov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Igor Korolyov
Участник
Hi Sergey!

Не надо только COLLATE сюда прицеплять!!! Там вообще сложно предсказать что
к чему, учитывая что CHR(0)=CHR(1) и т.п.
Конечно нужно в MACHINE экспериментировать...
А насчёт "неиспользования" строк - помнится вплоть до VFP7 был глюк с
Integer-полями - поскольку их внутреннее представление бинарно, и по сути не
отличается от набора CHR(xx)...
Numeric поля насколько я в курсе, тоже хранятся внутри индекса в бинарном
виде (как Double). Так что не зря MS отключило в таких ситуациях оптимизацию
(точнее использование "чужих" индексов), совсем не зря...

Posted via ActualForum NNTP Server 1.2
...
Рейтинг: 0 / 0
22.07.2005, 04:42:06
| Ответить | Цитировать | Написать  
(VFP 9.0) Первое крупное неудобство в VFP 9.0
    #33179413
Sergey Ch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sergey Ch
Участник
Igor KorolyovТак что не зря MS отключило в таких ситуациях оптимизацию (точнее использование "чужих" индексов), совсем не зря...
OK, будем пользоваться индексами с осторожностью
...
Рейтинг: 0 / 0
22.07.2005, 10:05:29
| Ответить | Цитировать | Написать  
19 сообщений из 19, страница 1 из 1
Форумы / FoxPro, Visual FoxPro [игнор отключен] [закрыт для гостей] / (VFP 9.0) Первое крупное неудобство в VFP 9.0
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=41&msg=33172362&tid=1593823]:
 0ms
get settings:
 7ms
get forum list:
 13ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 183ms
get topic data:
 7ms
get forum data:
 2ms
get page messages:
 37ms
get tp. blocked users:
 1ms
others: 196ms
total:  450ms
созд. / загр.: 450ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]