Форум: "Базы";
Текущий архив: 2003.12.19;
Скачать: [xml.tar.bz2];
Вниз
TMemoField в TClientDataSet Найти похожие ветки
← →
Michail Dalakov (2003-11-24 12:01) [0]Может кто знает как решить проблему показа полей типа TMemoField в TClientdataset при Fetch довольно большого количества записей
Используется D7, при Fetch небольшого количества записей все ОК! Как только количества записей становится достаточно большим в некоторых строках вместо реальных значений появляются Null
← →
Nikolay M. (2003-11-24 12:15) [1]Не встречал такого. FetchBlobsOnDemand не пробовал ставить?
← →
Michail Dalakov (2003-11-24 12:58) [2]FetchBlobsOnDemand пробовал раньше - не помогало. Сейчас попробовал повторно кроме тормозов (?) ничего не получил. На самом деле поля Memo в DB нет, оно получается в результате того,
что SQL запрос возвращает значение в виде объединения строк разделенных символом #13, но дело я думаю не может быть в этом.
← →
Sunches (2003-11-24 16:29) [3]У меня нечто подобное было, но связано было с неправильным выбором значений для параметра TDatabase.Params
BLOBS TO CACHE и поля TClientDataSet PacketRecords.
Когда PacketRecords отличен от -1, то он должен быть меньше BLOBS TO CACHE
← →
Michail Dalakov (2003-11-24 20:37) [4]Спасибо. Параметр PacketRecords действительно влияет но не является решением проблемы. Лучший вариант получается при PacketRecords=-1, в этом случае значение в первом Memo поле почти полностью присутствуют, зато во втором сплошные Null.
Интересно, что если кинуть данные из Query в грид, то все OK!
← →
Sunches (2003-11-25 16:03) [5]Это скорее всего происходит потому, что грид FetchBlobs делает пока по каждой записи проходит.
← →
Michail Dalakov (2003-11-25 19:44) [6]Нет FetchBlobs это метод TCustomClientDataSet.
← →
Michail Dalakov (2003-11-26 20:21) [7]Ну может кто-то еще что-то полезное скажет. Уж очень не хочется лопатить библиотеки Delphi, а вызывать функцию на сервере возвращающую набор данных и руками перебивать в TClientDataSet не
представляется разумным.
← →
Nikolay M. (2003-11-26 21:58) [8]Танцевать нужно от печки
1) Сервер БД - ?
2) Средства доступа - ?
3) Снифер/профайлер/SQL monitor или что там у тебя, показывают, что данные ушли на клиента или это проблема на сервере?
← →
Michail Dalakov (2003-11-26 22:09) [9]1. oracle
2. BDE
3. Проблема всего в связке TDataSetProvider - TClientDataSet
ибо как я говорил раньше, если запихнуть SQL в TQuery открыть
его и визуализировать даные в DBGride, то все OK!
← →
ВладимирГоголев (2003-11-26 22:14) [10]Увы работа через с блобами и пр. данными большого объема реализована в vcl весьма косо, при фетчинге набора при установленной опции FetchBlobsOnDemand clientDataSet каждый блоб забирает отдельным пакетом через midas, т.е. значала все данные, первым пакетом, а потом по одной записи-пакет для блобов - тормоза дикие как раз в том режиме, который и предназначен для экономии ( мы изучив внимательно все что там сделано просто реализовали асинхронный фетчинг... Врагу не пожелаю, так что лучше стараться избегать таких наборов и придумывать соотв. интерфейсные решения
← →
Michail Dalakov (2003-11-26 22:40) [11]Дело в том, что физически в базе нет никакого блоба, я решил в целях оптимизации объединять строки на сервере:
select RTRIM(
DECODE(DVCLI.SNAME,Null,"", DVCLI.SNAME || CHR(13)) ||
DECODE(DVWHS.SNAME,Null,"", DVWHS.SNAME || CHR(13)) ||
DECODE(DVEMP.SNAME,Null,"", DVEMP.SNAME || CHR(13)) ||
DECODE(DVWAR.SNAME,Null,"", DVWAR.SNAME || CHR(13)) ||
DECODE(DVNA.SNAME,Null,"", DVNA.SNAME || CHR(13)) ||
DECODE(DVTAX.SNAME,Null,"", DVTAX.SNAME || CHR(13)) ||
DECODE(DVOUTL.SNAME,Null,"",DVOUTL.SNAME || CHR(13)) ||
DECODE(DVIS.SNAME,Null,"", DVIS.SNAME || CHR(13)) ||
DECODE(DVPRTMEAL.SNAME,Null,"",DVPRTMEAL.SNAME || CHR(13)) ||
DECODE(DVTRMTRT.SNAME,Null,"",DVTRMTRT.SNAME || CHR(13)) ||
DECODE(DVPRT.SNAME,Null,"", DVPRT.SNAME),CHR(13)) ANDT,
RTRIM(DECODE(CVCLI.SNAME,Null,"", CVCLI.SNAME || CHR(13)) ||
DECODE(CVWHS.SNAME,Null,"", CVWHS.SNAME || CHR(13)) ||
DECODE(CVEMP.SNAME,Null,"", CVEMP.SNAME || CHR(13)) ||
DECODE(CVWAR.SNAME,Null,"", CVWAR.SNAME || CHR(13)) ||
DECODE(CVNA.SNAME,Null,"", CVNA.SNAME || CHR(13)) ||
DECODE(CVTAX.SNAME,Null,"", CVTAX.SNAME || CHR(13)) ||
DECODE(CVOUTL.SNAME,Null,"",CVOUTL.SNAME || CHR(13)) ||
DECODE(CVIS.SNAME,Null,"", CVIS.SNAME || CHR(13)) ||
DECODE(CVPRTMEAL.SNAME,Null,"",CVPRTMEAL.SNAME || CHR(13)) ||
DECODE(CVTRMTRT.SNAME,Null,"",CVTRMTRT.SNAME || CHR(13)) ||
DECODE(CVPRT.SNAME,Null,"", CVPRT.SNAME),CHR(13)) ANCT,
TVOBJ.SNAME TVOBJ from TSPRC$ TSPRC, TVFIL$ TVFIL, TVACC$
DVACC, TVACC$ CVACC, TVCLI$ DVCLI, KLK.TVWHS$ DVWHS,
TVEMP$ DVEMP, TVWAR$ DVWAR, TVNA$ DVNA, TVTAX$ DVTAX,
TVOUTL$ DVOUTL, TVIS$ DVIS, TVPRTMEAL$ DVPRTMEAL,
TVTRMTRT$ DVTRMTRT, TVPRT$ DVPRT, TVCLI$ CVCLI, TVWHS$ CVWHS,
TVEMP$ CVEMP, TVWAR$ CVWAR, TVNA$ CVNA, TVTAX$ CVTAX,
TVOUTL$ CVOUTL,TVIS$ CVIS, TVPRTMEAL$ CVPRTMEAL, TVTRMTRT$ CVTRMTRT,TVPRT$ CVPRT, TVOBJ$ TVOBJ where TSPRC.DT between
to_date("01-01-2003","dd-mm-yyyy") and to_date("31-12-2003","dd-mm-yyyy")and TSPRC.TVFIL# = TVFIL.ID#(+) and TSPRC.DVACC# = DVACC.ID#(+) and TSPRC.CVACC# = CVACC.ID#(+) and TSPRC.DVCLI# = DVCLI.ID#(+) and TSPRC.DVWHS# = DVWHS.ID#(+) and TSPRC.DVEMP# = DVEMP.ID#(+) and TSPRC.DVWAR# = DVWAR.ID#(+) and TSPRC.DVNA# = DVNA.ID#(+) and TSPRC.DVTAX# = DVTAX.ID#(+) and TSPRC.DVOUTL#= DVOUTL.ID#(+) and TSPRC.DVIS# = DVIS.ID#(+) and TSPRC.DVPRTMEAL#=DVPRTMEAL.ID#(+) and TSPRC.DVTRMTRT# = DVTRMTRT.ID#(+) and TSPRC.DVPRT# = DVPRT.ID#(+) and TSPRC.CVCLI# = CVCLI.ID#(+) and TSPRC.CVWHS# = CVWHS.ID#(+)
and TSPRC.CVEMP# = CVEMP.ID#(+) and TSPRC.CVWAR# = CVWAR.ID#(+) and TSPRC.CVNA# = CVNA.ID#(+) and TSPRC.CVTAX# = CVTAX.ID#(+) and TSPRC.CVOUTL#= CVOUTL.ID#(+) and TSPRC.CVIS# = CVIS.ID#(+)
and TSPRC.CVPRTMEAL#=CVPRTMEAL.ID#(+) and TSPRC.CVTRMTRT# = CVTRMTRT.ID#(+) and TSPRC.CVPRT# = CVPRT.ID#(+) and TSPRC.TVOBJ# = TVOBJ.ID#(+)
Неужели прийдется возвращать весь набор полей и делать вычисляемое поле в TClientDataSet
← →
Michail Dalakov (2003-11-27 00:07) [12]Проблема решается если реально возвращаемая строка меньше 255 символов, тогда можно на сервере обрезать ее длину функцией SUBSTR до 255 и тогда вместо полей типа TMemoField будут созданы
TStringField и все OK!
Однако это не решает проблему показа полей типа TMemoField в TClientdataset при Fetch довольно большого количества записей.
Всем спасибо.
Если кто еще что скажет с интересом поучавствую.
← →
Nikolay M. (2003-11-27 08:25) [13]И все-таки, хотелось бы услышать еще ответ и на мой третий вопрос - уходят ли данные на клиента.
А что будет, если ты создашь у CDS Persistent-поля, удалишь TMemoField, руками создашь Data-поле ftString и укажешь у него размер 8192 (ну, или сколько тебе нужно).
Конечно, создать вычислимое поле - это всегда выход...
← →
Michail Dalakov (2003-11-27 11:56) [14]Насколько я понимаю уходят ли данные с СУБД на сервер приложений,
я не ловил запросы которые приходят на СУБД и данные которые передаются в этом конкретном случае, но думаю что да
(при Fetch TClientDataSet активизируется связаное с ним TQuery
которое засасывает порцию данных, дальше провайдер передает их
TClientDataSet).Нехочу повторяться, но раньше я говорил, что данные в TQuery нормальные, а в TClientDataSet нет и
проблема скорее всего в связке TDataSetProvider - TClientDataSet.
Может я не совсем правильно понимаю поставленный вопрос?
> А что будет, если ты создашь у CDS Persistent-поля, удалишь TMemoField, руками создашь Data-поле ftString
В этом случае exception о несоответствии типов, ожидается стринг,
actual:Memo
← →
Nikolay M. (2003-11-27 15:06) [15]
> Может я не совсем правильно понимаю поставленный вопрос?
Правильно понимаешь, просто для чистоты эксперимента хотелось бы увидеть и в связке с провайдером, что данные действительно ушли - чем черт не шутит.
Попробуй залоггировать все, что можно в OnGetData, BeforeRowRequest, BeforeGetRecords.
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2003.12.19;
Скачать: [xml.tar.bz2];
Память: 0.49 MB
Время: 0.009 c