Бърз начин за попълване на масив с данни от Query

Добър ден на всички.
Имам въпрос.

Са налични:

Запит1: TZMySqlQuery;

Unload_h = запис
дата: TDate;
id_ves: цяло число;
id_ves_unload: цяло число;
конозамент: низ;
id_own_unload: цяло число;
own_unload, ves_unload: низ;
край;

ArUnloadU: масив от Unload_h;

ClearQuery (Query1); // изчистване на данните от предишната заявка
Query1.Sql.Add ("Изберете дата, id_ves, id_ves_unload, ves_unload, conosament, id_own_unload, own_unload от load_h");
OpenDB (Запитване1); //Query1.Open, Query1.First и др.
SetLength (ArUnloadU, Query1.RecordCount);
// попълване на масива с данни от Query1
за i: = 0 до Length (ArUnloadU) -1 do
започнете
ArUnloadU [i] .id_ves: = Query1.fieldByName ("id_ves"). AsInteger;
ArUnloadU [i] .id_own_unload: = Query1.fieldByName ("id_own_unload"). AsInteger;
ArUnloadU [i] .id_ves_unload: = Query1.fieldByName ("id_ves_unload"). AsInteger;
ArUnloadU [i] .date: = Query1.fieldByName ("дата"). AsDateTime;
ArUnloadU [i] .ves_unload: = Query1.fieldByName ("ves_unload"). AsString;
ArUnloadU [i] .own_unload: = Query1.fieldByName ("own_unload"). AsString;
ArUnloadU [i] .conosament: = Query1.fieldByName ("conosament"). AsString;
Запитване 1. Следващо;
край;

Директен въпрос: има ли по-бърз начин за попълване на масива ArUnloadU ?
PS Няма нужда да предлагате използването на Query1.Fields вместо Query1.fieldByName.

и защо да карам данни в масив. кой е учил това? и защо е необходимо?

До Илш (19.10.04 06:28) [1]
Сравнете скоростта на работа с Query и с масив от данни и ще получите отговор.
И огромна молба: ако няма какво да се каже по същество на въпроса, тогава е по-добре да не пишете нищо.

Първо изтеглете цялата проба на клиента и след това сравнете скоростите. Във вашия цикъл това изтегляне се извършва.
ZY И колко записи трябва да върне вашата заявка?

вътре в ин! за сметка на паметта - така е, сър.
тази любов към масивите е болезнено подобна на вредните наклонности на Clippera. Виждал съм такива програми. И тогава те трябваше да бъдат пренаписани, защото масивите не се вписват в паметта:(
На пръв поглед не се виждат спестявания. И дори ако наистина сте го разбрали, най-вероятно той не е работил добре с Query.: (((
и сортирайте и филтрирайте, както искате масиви. няма да се изхабиш.
Добре? по същество.

> И колко лихва ще спечелите?
решението да се премине към използване на масиви от данни беше взето преди още две цели, така че няма да давам точни проценти, мога само да кажа, че увеличението на скоростта беше няколко пъти. И след промените, които правя сега, мисля, че скоростта ще се увеличи значително.
Сега ще се опитам да обясня причината за прехвърляне на данни в масив. Когато се анализира информация от тази таблица и свързаните таблици, е необходимо да се получат малки парчета информация от таблицата load_h. Ако ги получите чрез отговарящи на условията заявки в базата данни, това са стотици хиляди допълнителни заявки. Когато работите с няколко клиенти, тези заявки значително спират базата данни. Следователно беше взето решение да се прехвърлят данните в масива и в резултат на това да се прехвърли натоварването при извличане на информация на машината на потребителя. Вече писах за резултата.

> Има ли достатъчно памет за Select. от load_h
Паметта е достатъчна .

Илш (19.10.04 07:06) [5]
> по същество.
не

> има ли по-бърз начин за попълване на масива ArUnloadU
> ?

тогава няма друг начин като цяло.
между другото - колко време отнема прехвърлянето в масив?

Илш (19.10.04 07:52) [8]
> между другото - колко време отнема прехвърлянето в масив?
около 7 секунди, но компютърът ми е няколко пъти по-мощен от този на потребителите и те трябва да работят с програмата (зехтин:)).

> тогава няма друг начин като цяло тогава.
може би. Но нека изчакаме майсторите.

778112 записа на клиент - това е, което поражда съмнения
не можеш ли просто да го отрежеш като конец?
няма смисъл да дърпате толкова много записи.
по дата може да се филтрира или по друг начин
където използвайте

> Не е ли качена цялата селекция след изпълнението на Query.Open
> на клиент.

---