Что же делать с ключами

[zanuda]

Пишу
.LinkForm '.....
.....

.Create view testView
as
select *
FROM MBPIN, MBPMOVE, KATMBP, KATMOL
WHERE (( MBPIN.CSOPR == MBPMOVE.NREC AND
BPIN.CMBP == KATMBP.NREC AND
MBPMOVE.CMOLF== KATMOL.NREC ))
Он, ессно, требует ключи (с ограничением relation порядок standart Реализуется...).

Ежели ставлю noindex, то в полях
.fields
KATMOL.NAME
MBPMOVE.DMOVE
KATMBP.NAME
KATMBP.NNUMBER
MBPIN.KOLDOC
MBPIN.SUMMA
.endfields

ничего нет, т.е. при формировании отчета идут пустые строки ((
Чего я пропустил, можете объяснить как новичку??, в доках к сожалению ничего не нашел, а мучаюсь целый день.

[edward_K]

1. лучше в select все таки перечислить необходимые поля -быстрее будет отрабатывать.
2. в fields добавь "testview." перед каждым полем.

[zanuda]

Добавлял я в fields testView перед полем, такая же фигня...

Может ошибка все таки из-за ключей?

[Goblin]

Перечислять поля - бесполезно, без разницы на Pervasive SQL или на MS SQL, в любом случае будет на уровне системы выборка полного буфера записей для каждого узла логической таблицы, просто они невидимы будут для конфигуратора (ASDK четко это трактует для Атлантиса 3.хх.хх)

Вопрос тут в другом - каких ключей не хватает в данном запросе ??? Все на месте ...
Подцепка некорневых таблиц идет по NRec, индекс по нему есть, подобный запрос отрабатывает как часы ...

[WiRuc]

> Перечислять поля - бесполезно, без разницы на Pervasive SQL или на MS SQL, в любом случае будет на уровне системы выборка полного буфера записей для каждого узла логической таблицы, просто они невидимы будут для конфигуратора (ASDK четко это трактует для Атлантиса 3.хх.хх)

Как раз полезно, т.к. запросы к SQL Server формируются разные. В случае, когда поля указаны, выбираются только нужные поля, а если не указаны - то все. Соответственно, для производительности полезно указывать поля в запросах.

[zanuda]

Насчет того, выбирать все или нет - человек, бывший на курсах по галактике, сказал что все равно, выбирать ли все, или же указывать поля, все равно галактика берет всё.

А насчет того что ..."Вопрос тут в другом - каких ключей не хватает в данном запросе Все на месте ...
Подцепка некорневых таблиц идет по NRec, индекс по нему есть, подобный запрос отрабатывает как часы "...

Дак он ругается при такой связке как я говорил - "С ограничением Relation порядок Standart реализуется на внешней выгрузке"

По моему это именно про ключи. Только какие не говорит.

А если что в SQL это выглядит так

...FROM dbo.T$MBPIN INNER JOIN
dbo.T$MBPMOVE ON dbo.T$MBPIN.F$CSOPR = dbo.T$MBPMOVE.F$NREC INNER JOIN
dbo.T$KATMBP ON dbo.T$MBPIN.F$CMBP = dbo.T$KATMBP.F$NREC INNER JOIN
dbo.T$KATMOL ON dbo.T$MBPMOVE.F$CMOLF = dbo.T$KATMOL.F$NREC

И выдает пустые строки.....
Ну кто нибудь, ответьте, как вы побеждали это сообщение (ошибку)???? :-/

[WiRuc]

>Насчет того, выбирать все или нет - человек, бывший на курсах по галактике, сказал что все равно, выбирать ли все, или же указывать поля, все равно галактика берет всё.

Бред. Посмотрите профайлером запросы к MSSQL и вы увидите большую разницу между SELECT * FROM ... и SELECT какие-то поля FROM ...
У меня складывается ощущение, что они сами на этих курсах не понимают, что происходит внутри Галактики. Совсем недавно раскопал, что на платформе MSSQL не работают семафоры с русскими наименованиями, а они активно используются в Галактике.

[zanuda]

"...а они активно используются в Галактике."
От темы не уходим.

Ну кто нибудь? :`(

[IStep]

1)Такое собщение выдаётся, когда стоит сортировка (ORDER BY ), но нет соотв. индекса
..а ";" для .Create view я не вижу.
Может где-то ORDER BY затерялся.
...Хотя FCOM это дело перемалывает.

2) в таблицах Данные есть?? MBPIN точно не пустая?

[zanuda]

Да, там стоит в конце ORDER BY KATMBP.NNUMBER;
Но я же пишу SELECT * , какая ему разница...

Ок, убрал ORDER BY, ошибка не выдается, но пустые строки так и остались пустыми.
Нет, MBPIN точно не пустая. В SQL ENTERпрайзе для тестовой есть данные в этой таблице. Я тоже в тестовой в галактике. Что за ......
В каком случае, кроме пустой таблицы, не выводятся данные??

[edward_K]

мне кажется, что вам пора привести полный текст вашей ард.
order by без индекса иногда ломает отчет - в sql можете убедиться.
по возможности лучше уходить от сообщения " внешняя выгрузка". Кроме того все таки перечислите необходимые поля в select и подпишите их (fieldname=XXXX) и в fields
укажите именно их. Сюдя по fields я могу предположить что у вас не выведуться поля с katmol и katmbp, поскольку при таком написании вам нужно по ним дополнительно спозиционироваться - добавить либо цикл по ним(что вроде как противоречит логике) - .{ table 'testview.katmol',либо в програмном блоке написать testview.getfirst katmol.
А по поводу перечислений полей и быстродействия можете не спорить - проверенно - чем меньше полей указано тем быстрее работает отчет, хотя при необходимости обратиться к другим полям все равно можно, правда на маленьких базах вы это не увидите.

[Goblin]

WiRuc, не бред, а объективная реальность ...
И на курсах народ обучающий тож не особо квалифицирован - они так , для начинающих , тебе это старики типа Maverick'а подтвердят .
Не надо путать то,что ты написал SQL Query Analyzer и то , что переслало серверу MS SQL ядро системы ... Ты уверен что ядро галактики через соответсвующую DLL для работы с MS SQL пересылает именно запрос по конкретным полям, а не по всем ? Я нет - потому как знаю , что основа ядра писалась изначально под Pervasive, который до недавнего времени был просто очень шустрым менеджером записей(SQL в нем более-менее вменяемый появился лишь с версии PSQL 2000) и писалось в то время, когда Oracle был дорогущей роскошью, а MS SQL из коротких штанишек не вырос ...
Основа работы с таблицами БД в нем - буфер записи, записи идентифицируются по смещению и размеру, описанному в словаре, и без него , т.е. без выборки всех полей записи тут не обойтись. Это было есть и будет в на любом Atlantis-приложении вплоть до последних версий(не знаю, как там в 5-ом Атлантисе, но на третьем только так).
Ну ладно , это лирика ...

Теперь про ключи - ты б лучше весь исходник формы привел, а не кусок лог. таблы, тогда легче понять где собака порылась ...

[Goblin]

Сорри, не записи, а поля идентифицируются по смещени/размеру ...
очепятка ...

[zanuda]

.LinkForm 'EDD_RREE_MBP_04' Prototype is 'rRee_MBPProt'
.Group 'Подробный реестр вводов в эксплуатацию'
.NameInList 'Ведомость выдачи в эксплуатацию_изм'
.var
NumDocs:LongInt
ReeItog:Double
.endvar
.Create view testView
var UnitedKod:Double
as
select
MBPMOVE.DMOVE(fieldname=dateF),
MBPIN.SUMMA(fieldname=StoimF),
KATMBP.NAME(fieldname=MBPName),
MBPIN.KOLDOC(fieldname=kolF),
KATMBP.NNUMBER(fieldname=MBPKod),
KATMOL.NAME (fieldname=MOLFROM)

FROM MBPMOVE, MBPIN, KATMBP, KATMOL
WHERE (( MBPIN.CSOPR == MBPMOVE.NREC AND
MBPIN.CMBP == KATMBP.NREC AND
MBPMOVE.CMOLF== KATMOL.NREC ))
//ORDER BY KATMBP.Name;
.fields
CommonFormHeader
'Данные предприятия'
MOLFROM//testView.KATMOL.NAME
dateF//testView.MBPMOVE.DMOVE
MBPName//testView.KATMBP.NAME
MBPKod//testView.KATMBP.NNUMBER
SubStr( fEd, 1, 10)
kolF//testView.MBPIN.KOLDOC
fPrice
StoimF//testView.MBPIN.SUMMA
ReeItog
SubStr(fMOLFr,1,35)
.endfields

.begin
testview.getfirst;
ReeItog := 0;
end.

Вот. Извиняюсь за прошлое сообщение, не знаю что вышло, наверно из-за символов... ))

После того как поставил .GetFirst данные начали заливаться в поля. Ошибка "с ограничением Relation..." выводится, когда я пытаюсь по не ключевым полям отсортировывать.
Но что же теперь делать, очень нужна сортировка (группировки вроде тут вообще нет).
Причем сортировка не по ключевым полям. Выход один? Временная таблица? А разве это возможно в стандартном отчете?

[WiRuc]

2 Туманов
Если бы я плотно не работал с MSSQL, то я бы голословно такое не говорил:)
Все уже давно изучено. Смотрел запросы, идущие непосредственно к ядру MSSQL через ODBC(через профайлер+ODBC tracing). Все запросы к MSSQL Atlantis оформляет в хранимые процедуры. И лично делал тесты, какие ХП создаются в случае указания полей в view и при отсутствии указания полей. Поверьте, эти ХП различаются в плане выборок полей. А если, например, написать RecordExists katsopr, то к MSSQL пойдет запрос вида select 1 from t$katsopr. А в случае, GetFirst katsopr запрос примет вид select список_полей from t$katsopr. Поэтому, использование RecordExists предпочтительней для проверки наличия записи.
Еще раз повторяю, запрос всех полей НЕ ДЕЛАЕТСЯ, если в view указан список полей.