как просмотреть не корневую вьюху??

[Alexander]

Пример:

Код: Выделить всё

Interface test 'test' doaccept, cyan;
   Create View vKatOrg
     select * from katorg;

   Create View vKatSopr
     select * from KatSopr;

   tabbedsheet tabs;
     browse b1 'KatOrg';
        table KatOrg;
        Fields
           nrec;
           name;
     end;
     browse b1 'KatSopr';
        table katSopr;  //Компилятор ругается vKatSopr.KatSopr - тоже не проходит
        Fields
           nrec;
           name;
     end;
     
   end;
End.

[Goblin]

Делайте одной вьюхой и будем вам счастие ...
Не знаю как в 5-ом атлантисе, но в 3-ем компилятор лепит в интерфейсе только 1 вьюху с таким же как и у интерфейса именем (так что именовать вьюху здесь смысла нет).
В имеющихся обрывках исходников Галактики 5.85.01 , нажитых неправедным путем , в интерфейсах вьюхи не именуются вообще и всегда только в одном экземпляре

P.S. Кстати, в fields'ах желательно польные имена полей указывать , т.е Katsopr.Nrec, Katsopr.Name

[Алексей]

Goblin
сиди где сидишь, за тобой уже идут!

Alexander
филдсы вообще желательно не указывать, тогда она выберет только те которые будут использоватся. как показала практика, выборка ускоряется значительно
пример: create view from katorg ...

ну и не надо две выборки - делай всё в одной, если нужно два раза таблицу по разным критериям взять - используй синонимы

[Goblin]

Alexander
филдсы вообще желательно не указывать, тогда она выберет только те которые будут использоватся. как показала практика, выборка ускоряется значительно
пример: create view from katorg ...

Стоп-стоп-стоп ...
Не буду говорить про SQL-версии на Oracle/MS SQL , но на Pervasive независимо от того, указали или нет поля - всегда будут выбираться все поля в операции клиент-сервер. Так работает ядро Pervasive, не знающее ничего о структуре полей записи. Оно оперирует лишь буфером записи и смещением/размером для индексов. Поля - это уже надстройка над ядром. В Pervasive SDK это прописано четко.
Так что особой разницы на Pervasive SQL не должно быть

[Алексей]

Goblin
Про бтрив не знаю - спорить не буду.
Но на SQL разница есть точно, и иногда достигала 40% производительности на больших объемах выборки.