Lookup по полю типа Guid

[Poleax]

Есть таблица1, там первое поле типа Guid. По этому полю кластерный индекс.
Создана форма1 по этой таблице1.
Поле на основе Guid это EDT c relations на таблицу1.

В таблице2, создано поле по EDT Guid из таблицы1.
Открываю форму2 выбираю lookup по этому полю.
При повторном выборе lookup, курсор не становится на нужную строку с известным guid.

Переход к основной таблице тоже автоматически не ставить курсор в гриде. (На форме1 в DataSource индекс проставлен по таблице1)

Почему так происходит? Почему по guid не перемещается курсор?
Это как то связано с guid? По остальным вариантам, если поле не типа guid, курсор нормально.

[kornix]

Poleax, а что значит курсор не перемещается по GUID? Можешь скрин выложить?

[Poleax]

Маленький проект для примера Вложение 6194

Имеем Form1. Строки создаются просто Ctrl+N Guid автоматом генерится.


Получаем странный lookup. Курсор в гриде лукапа не на месте.
Form2


Проект \Projects\Shared\Project_GuidLookup состоит из:
\Data Dictionary\Tables\Table1
\Data Dictionary\Tables\Table2
\Data Dictionary\Extended Data Types\testGuid
\Forms\Form1
\Forms\Form2
\Menu Items\Display\Table1

[kornix]

Стал перекрывать лукап программно, либо я что-то не так делаю, либо в аксапте не предусмотрено перекрытие лукапа для контролов типа Guid. Открыл класс SysTableLookup, метод performFormLookup():

void performFormLookup()
{
    FormStringControl   callingStringControl;
    FormIntControl      callingIntControl;
    FormInt64Control    callingInt64Control;
    FormDateControl     callingDateControl;
    FormGuidControl     callingGuidControl; // добавил новый вид контрола, его почему-то не было
    if (!callingControl)
        throw(error(Error::wrongUseOfFunction(funcname())));

    switch (callingControl.handle())
    {
        case classnum(FormStringControl):
            callingStringControl = callingControl;
            callingStringControl.performFormLookup(this.formRun());
            break;
        case classnum(FormIntControl):
            callingIntControl = callingControl;
            callingIntControl.performFormLookup(this.formRun());
            break;
        case classnum(FormInt64Control):
            callingInt64Control = callingControl;
            callingInt64Control.performFormLookup(this.formRun());
            break;
        case classnum(FormDateControl):
            callingDateControl = callingControl;
            callingDateControl.performFormLookup(this.formRun());
            break;
        // без этого изменения лукап не работает (перекрытый) -->
        case classnum(FormGuidControl):
            callingGuidControl = callingControl;
            callingGuidControl.performFormLookup(this.formRun());
            break;
        // без этого изменения лукап не работает (перекрытый) <--
    }
}

Теперь не могу сообразить, как же работает стандартный лукап по EDT с типом Guid, и почему под это не приспособлен такой вариант лукапа?

[kornix]

Судя по всему лукап по полю с типом Guid работает без позиционирования на текущем выбранном элементе. Можно выбрать другое решение, чтобы не дописывать стандартные классы - перекрыть лукап по какому-нибудь другому полю, тоже уникальному в Table1, а в методе lookup() на поле добавить только колонку с Guid. Будет полноценный выбор Guid'а:

public void lookup()
{
    Query                   query = new Query();
    QueryBuildDataSource    qbds;
    SysTableLookup          sysTableLookup = SysTableLookup::newParameters(tablenum(Table1), this);
    ;

    sysTableLookup.addLookupfield(fieldnum(Table1, testGuid));
    qbds = query.addDataSource(tablenum(Table1));
    sysTableLookup.parmQuery(query);
    sysTableLookup.performFormLookup();

}

Другого решения не нашел. Если придумаете - напишите, пожалуйста

[AndyD]

Проблема в том, что MS SQL хранит и сортирует GUID (или UNIQUEIDENTIFIER) не в виде текста, а в виде 16-байтного числа. Причем, порядок следования экстентов не соответствует текстовому виду (последние экстент идет впереди).

По-этому, сортировка по GUID будет отличиться от текстового представления.

[Poleax]

Цитата:

Сообщение от AndyD

Проблема в том, что MS SQL хранит и сортирует GUID (или UNIQUEIDENTIFIER) не в виде текста, а в виде 16-байтного числа. Причем, порядок следования экстентов не соответствует текстовому виду (последние экстент идет впереди).

По-этому, сортировка по GUID будет отличиться от текстового представления.

Цитата:

Сообщение от kornix

Судя по всему лукап по полю с типом Guid работает без позиционирования на текущем выбранном элементе. Можно выбрать другое решение, чтобы не дописывать стандартные классы - перекрыть лукап по какому-нибудь другому полю, тоже уникальному в Table1, а в методе lookup() на поле добавить только колонку с Guid. Будет полноценный выбор Guid'а:

public void lookup()
{
    Query                   query = new Query();
    QueryBuildDataSource    qbds;
    SysTableLookup          sysTableLookup = SysTableLookup::newParameters(tablenum(Table1), this);
    ;

    sysTableLookup.addLookupfield(fieldnum(Table1, testGuid));
    qbds = query.addDataSource(tablenum(Table1));
    sysTableLookup.parmQuery(query);
    sysTableLookup.performFormLookup();

}

Другого решения не нашел. Если придумаете - напишите, пожалуйста

С переходом к основной таблице тоже типа такой баг? Как нибудь решается, без насильственного программирования?

[kornix]

Цитата:

Сообщение от AndyD

Проблема в том, что MS SQL хранит и сортирует GUID (или UNIQUEIDENTIFIER) не в виде текста, а в виде 16-байтного числа. Причем, порядок следования экстентов не соответствует текстовому виду (последние экстент идет впереди).

По-этому, сортировка по GUID будет отличиться от текстового представления.

Действительно, причем в аксапте даже селект написать для выборки guid'а нельзя. Вот оно, объяснение

[tricky]

Цитата:

Сообщение от Poleax

С переходом к основной таблице тоже типа такой баг? Как нибудь решается, без насильственного программирования?

Думаю лучше вообще отказаться от ключевого поля типа Guid, а использовать String с заполнением его типа

guid2str(newGuid())

.

[kornix]

Цитата:

Сообщение от Poleax

С переходом к основной таблице тоже типа такой баг? Как нибудь решается, без насильственного программирования?

Да, при переходе к основной таблице та же проблема - нет фильтрации по Guid. Единственное решение на мой взгляд - лукап по другому уникальному полю, и отображение в лукапе вашего столбца с guid'ом.

[AndyD]

Кстати, Аксапта сама при открытии лукапа или переходе к основной таблице передает идентификатор "00000000-0000-0000-0000-000000000000", так что в любом случае не будет работать нормально.

[Poleax]

Цитата:

Сообщение от tricky

Думаю лучше вообще отказаться от ключевого поля типа Guid, а использовать String с заполнением его типа

guid2str(newGuid())

.

Этого бы как раз не хотелось.

[AndyD]

Еще один момент.

По-моему, не самый лучший подход использовать GUID (и вообще любое случайно генерируемое значение) в качестве кластерного ключа.
В случае интенсивного добавления записей будет происходить перестройка страниц с уже существующими данными, что приведет к существенно большим блокировкам, чем при использовании простого возрастающего идентификатора

[Poleax]

Цитата:

Сообщение от Poleax

Переход к основной таблице тоже автоматически не ставить курсор в гриде. (На форме1 в DataSource индекс проставлен по таблице1)

Дописываем. Вызываем метод возвращающий guid на "родительской" форме, далей просто курсор в запросе ставим на нужную запись.:
В \Forms\Form1

//\Forms\Form1\Methods\classDeclaration
public class FormRun extends ObjectRun
{
    guid    _guid;
}

//\Forms\Form1\Methods\init
public void init()
{
    Object callerFromRun = element.args().caller();
    ;

    if (callerFromRun && formhasMethod(callerFromRun, identifierstr(getTestGUID)))
    {
        _guid  = callerFromRun.getTestGUID();
    }

    super();
}

//\Forms\Form1\Data Sources\Table1\Methods\executeQuery
public void executeQuery()
{
    Table1   _table1;
    ;

    super();

    if(_guid)
    {
        _table1 = Table1::find(_guid);
        Table1_ds.findRecord(_table1);
    }

}

\Forms\Form2

//\Forms\Form2\Methods\getTestGUID
guid getTestGUID()
{
    return Table2.testGUID;
}

Вложение 6213

[AndyD]

У вас таблица большая?

В общем, не надо так делать - иначе получите большие тормоза в неожиданном месте

[Poleax]

Цитата:

Сообщение от AndyD

У вас таблица большая?

В общем, не надо так делать - иначе получите большие тормоза в неожиданном месте

Что не надо? Какие тормоза?
Таблица не большая < 5 тысч записей

[AndyD]

тормоза при переходе к вашей форме.

[Poleax]

Цитата:

Сообщение от AndyD

тормоза при переходе к вашей форме.

Тормозов нет и не будет. По guid есть индекс. Все нормально работает, вопрос с переходом решен, так как стандартного нет.

[gl00mie]

Цитата:

Сообщение от Poleax

Что не надо? Какие тормоза?

Не надо findRecord() использовать, если нет уверенности, что таблица будет реально маленькой При неудачном стечении обстоятельств для выполнения findRecord() клиент может засосать всю таблицу к себе в оперативку (были прецеденты).

[Poleax]

Цитата:

Сообщение от gl00mie

Не надо findRecord() использовать, если нет уверенности, что таблица будет реально маленькой При неудачном стечении обстоятельств для выполнения findRecord() клиент может засосать всю таблицу к себе в оперативку (были прецеденты).

Что рекомендуешь вместо findRecord?