Re: Грабли с кэшем данных
7. Идем обратно, в начало нашего множества. И там мы её тоже видим. Ясный пень, я понимаю почему это происходит. А я - нет, объясни На пустой таблице это делается так. 0. Выполняем запрос select * from TABLE. Фетч не делаем. 1. Юзер добавляет запись в гриде - Клиент добавляет запись во внутренний кэш - Клиент выполняет запрос INSERT INTO и запись попадает в таблицу 2. Юзер видит добавленную запись. 3. Юзер начинает движение вниз по гриду. - Клиент делает фетч и выбирает запись, которую мы добавили в п.2.2. И он её снова добавляет в кэш таким образом, одна и та же запись дважды фигурирует в кэше. --- В IBE с пустыми таблицами тест не провернешь. Он начинает делать фетчи чтобы заполнить видимую часть грида. Поэтому там надо забить в таблицу побольше данных. Чтобы, после того как мы добавим новую запись, он смог продолжить фетч и выбрать эту запись снова. Коваленко Дмитрий.
Re: Грабли с кэшем данных
7. Идем обратно, в начало нашего множества. И там мы её тоже видим. Ясный пень, я понимаю почему это происходит. А я - нет, объясни На пустой таблице это делается так. 0. Выполняем запрос select * from TABLE. Фетч не делаем. 1. Юзер добавляет запись в гриде - Клиент добавляет запись во внутренний кэш - Клиент выполняет запрос INSERT INTO и запись попадает в таблицу 2. Юзер видит добавленную запись. 3. Юзер начинает движение вниз по гриду. - Клиент делает фетч и выбирает запись, которую мы добавили в п.2.2. И он её снова добавляет в кэш таким образом, одна и та же запись дважды фигурирует в кэше. Т.е. в клиентском кеше ? В датасете ? И в чём проблемы идентифицировать отфетченную запись и оставить в кеше что-то одно ? И, главное, причём тут доработка со стороны сервера ? -- Хорсун Влад
Re: Грабли с кэшем данных
Т.е. в клиентском кеше ? В датасете ? И в чём проблемы идентифицировать отфетченную запись и оставить в кеше что-то одно ? В чем проблемы, говоришь? Бугага. Да во всем. И, главное, причём тут доработка со стороны сервера ? Пусть он (курсор) не возвращает записи, которые добавились после начала выполнения запроса. Вообще говоря, тут надо по другому сказать - Пусть курсор не видит изменения, которые произошли в БД после его открытия. Коваленко Дмитрий.
Re: Грабли с кэшем данных
Kovalenko Dmitry ... Т.е. в клиентском кеше ? В датасете ? И в чём проблемы идентифицировать отфетченную запись и оставить в кеше что-то одно ? В чем проблемы, говоришь? Бугага. Да во всем. Научить PK объявлять и работать с ним ? :-D Кстати, тот самый, достаточно редкий случай, когда DBKEY может помочь. И, главное, причём тут доработка со стороны сервера ? Пусть он (курсор) не возвращает записи, которые добавились после начала выполнения запроса. Вообще говоря, тут надо по другому сказать - Пусть курсор не видит изменения, которые произошли в БД после его открытия. Ну, жди... :) -- Хорсун Влад
Re: Грабли с кэшем данных
Ну, жди... :) Дык, это мое перманентное состояние :-) Чередуемое с периодами беснования :-))) Коваленко Дмитрий.
Re: Грабли с кэшем да нных
Kovalenko Dmitry wrote: 0. Выполняем запрос select * from TABLE. Фетч не делаем. 1. Юзер добавляет запись в гриде - Клиент добавляет запись во внутренний кэш - Клиент выполняет запрос INSERT INTO и запись попадает в таблицу Вот тут и косяк. Иделогически датасет дожен либо сделать предварительно FetchAll или Refresh после инсерта. Если инсерт ещё и с сохранением ордера, то ситуация ещё более очевидна.
Re: Грабли с кэшем данных
0. Выполняем запрос select * from TABLE. Фетч не делаем. 1. Юзер добавляет запись в гриде - Клиент добавляет запись во внутренний кэш - Клиент выполняет запрос INSERT INTO и запись попадает в таблицу Вот тут и косяк. Иделогически датасет дожен либо сделать предварительно FetchAll или Refresh после инсерта. Либо перед первой вставкой форсированно загружать все множества. И тут тоже можно нарваться :) Про рефрешЪ я не думал - потому что тут думать нечего. Не катит :-)) Если инсерт ещё и с сохранением ордера, то ситуация ещё более очевидна. Кругом засада :)) --- Предлагаю крайним сделать сервер - пусть создает стабильные курсоры. EUSUS. Коваленко Дмитрий.
