» прикладное программирование и не только оно...

XPerformer
да мне не хочется ставить лишние компоненты, я попробую или свою написать, основанную на потоках, или возьму расписание от девок, правда они монструозные( в любом случае, взял на заметку, спасибо еще раз

если у вас не получилось добавить даже два таймера )), значит, лучше довериться готовому классу. Тем более это не компоненты, ставить их не надо - только добавить в uses Cromis.Scheduler

Добавлено:
mdid
кстати, вы бы код свой показали, там думаю банальная ошибка

XPerformer
код уже удалил, но там было все просто
был динамический массив таймеров, создавались они обычно

Код: mas[i]:= TTimer.create(self);
mas[i].enabled:=false;
mas[i].interval

Цитата:

был динамический массив таймеров, создавались они обычно

А ликвидировались как?

Цитата:

А ликвидировались как?

да, тоже недавно столкнулся с аналогичной проблемой, оказалось банально не освобождал ресурсы и в итоге переполнение памяти.

никак, это был ВТОРОЙ динамически созданный таймер. ВТОРОЙ, я просто еще не успел заняться размножением
тут может быть какая то кака с другими компонентами. В любом случае, это уже не актуально

Вот они чем отличаются баг и фича
http://s40.radikal.ru/i087/1409/78/af0b0b38cb32.jpg

SuPriTo
более художественное
http://iris-hime.deviantart.com/art/Bugs-and-Features-179764485
http://morethancoding.files.wordpress.com/2011/07/badly-designed-features-transparent1.png

XPerformer
на работе висит такая http://community.spiceworks.com/shared/post/0000/4674/bug_vs_feature.gif
порадовала 2 инкарнация бана by design

protoror
я чет-то не понял, что у него с костюмом
обои в детскую юному программисту
http://lh5.ggpht.com/-apxSlHMu8Dw/VBFJgyqEmmI/AAAAAAAACCE/F-x6VZyEGUA/s0/Bugs-Seamless-Patterns.jpg

вах, прикольные обои))) жаль дети не оценят)))

Добрый день.
Есть linux с postgreSQL, программа( Delphi 2010, PgDAC). Как сделать так чтобы не создавать под каждую таблицу Query. Щас Query использую шт 10 и таблиц 50, при открытии таблицы переключаю т.е. жонглирую ими и форму открываю showmodal-но. А как можно это организовать? Т.е. открывать за раз неизвестное кол-во таблиц и править их как в 1с.

Добавлено:
если можно с примером

Ahaltek
Обычно досаточно одного - двух query, sql запрос только менять и все, текстом любую базу можно приписать в from
З.Ы. А составить объединенный sql запрос религия не позволяет?
https://ru.wikipedia.org/wiki/Join_%28SQL%29

protoror
Я так понял если данные сохранять локально в файлы то можно парой обойтись.

A если одна таблица открыта(одна query) + она же в другой форме открыта для редактирования с выбором некоторых полей(DBComboBox-ы 'организация'(query 2), 'банк'(query3)...и т.д.)+ открыть еще форму с другой таблицей и т.д.. И это одновременно.
Или допустим 5 таблиц открыть одновременно в разных окнах и они все видны. Как тут парой обойтись?

Ahaltek
По мне дак когда открыто столько квери это проблема с юзабилити.
не представляю для чего открывать 5 штук

а как можно сделать?
в 1с хоть скока открывай таблиц..

Добавлено:
Запрос сделал парой квери, а в чем хранить данные что бы их видно было? Как только квери использую для другого запроса в Gride данные поменяются.

Ahaltek

Цитата:

а как можно сделать?

1. Либо на уровне оптимизации sql запросов.
2. Либо на уровне оптимизации интерфейса. Например, не выводить все эти окна одновременно, а только по запросу. Неужто все 50 таблиц нужны и с ними работает пользователь. Пользователь все равно работает с 1 или 2 запросами, все остальное можно получать по требованию.
3. Либо копированием данных из запросов в локальные данные - например, в память или на диск, но тут возникает проблема синхронизации. Кроме того, если доступ к базе осуществляется быстро, то не имеет смысла копировать данные локально, легче их из базы получить.
Далее вам решать, как поступить.

Цитата:

в чем хранить данные что бы их видно было?

Сделали query, который не связан с Grid, результат скопировали в память, удалили query. Если нужно связать с гридом, то воспользовались специальным компонентом, который позволяет данные, сохраненные в памяти, выводить в grid.

SuPriTo

Так если в память грузить потом все равно нужна синхронизация памяти и сервера.
Раз нет?
А кокой компонент посоветуете использовать если грузить в память?

Добавлено:
установлено PgDAC. Но использую тупо conect и Query

Цитата:

Так если в память грузить потом все равно нужна синхронизация памяти и сервера.

Цитата:

Либо копированием данных из запросов в локальные данные - например, в память или на диск, но тут возникает проблема синхронизации.

Да. Поэтому лучше оптимизировать запросы и/или интерфейс программы и/или перейти на хранимые процедуры, вместо sql запросов (если они поддерживаются)

Цитата:

А кокой компонент посоветуете использовать если грузить в память?

FireDac - TFDMemTable
ehLib - TMemTableEh (сам пользуюсь этим)
Но есть другие, где-то проходил тут тест, какой компонент лучше. Попробуйте поискать по форуму.

вот ссылка если чего
http://forum.ru-board.com/topic.cgi?forum=33&topic=8529&start=5760#20

SuPriTo
В ehLib использовал только Grid.
А TMemTableEh каждый раз создавать для отображения таблицы и при закрытии уничтожать?

Цитата:

А TMemTableEh каждый раз создавать для отображения таблицы и при закрытии уничтожать?

Да, как вам удобнее, так делайте. Я лично в своем проекте, раз туда данные загрузил и держал до тех пор, пока они нужны, потом закрывал.

A еще вопрос как синхронизировать? компонентами(если есть) и/или ручками?
Плиз дайте направление

Добавлено:
Тогда получается для тех таблиц которые будут открыты нужно добавлять TMemTableEh.
И если я захочу 10 открыть ... то понадобиться 10 TMemTableEh.
Интересно в 1с как? Там ведь кол-во таблиц не ограничено.

Ahaltek
В 1с 8.х - если просто в памяти таблицу (ТаблицуЗначений) создать - то сколько хошь,
а вот если на форме отображать - то либо нужное кол-во компонент на форму кидать,
либо каждый раз компоненте источник данных (т.е., таблицу) переназначать,
либо вперемешку и то, и другое...

Цитата:

A еще вопрос как синхронизировать? компонентами(если есть) и/или ручками?
Плиз дайте направление

Для того, чтобы дать ответ на этот вопрос - нужно знать, что за проект вы делаете. Скорее всего ручками придется это делать. Но я уже говорил, может быть легче интерфейс переделать или оптимизировать запросы (query). Можно ведь просто создать query без Grid и бегать по записям и будет тебе тот же TMemTableEh. И тогда ничего не нужно усложнять. Мне кажется, что вы усложняете вещи, которые можно сделать очень просто. TMemTableEh нужен, если в логике приложения необходима обработка данных или ускорение доступа к данным.
Не правильно сравнивать ваше приложение и 1с. Вторая - это среда разработки бухгалтерских программ.

Цитата:

Не правильно сравнивать ваше приложение и 1с. Вторая - это среда разработки бухгалтерских программ.

золотые слова

платиновые

SuPriTo

Цитата:

нужно знать, что за проект вы делаете

Проект - делопроизводство отдела закупа. Знаю что есть конф-я 1с "Делопроизводство"(не придлогать ). Смысл примерно такой: приходит заявка(таб1) под номером(на товары, на услуги) от нее создается договор(местные(таб2) и зарубежные(Таб3)) с приложениями допсогашениями (таб4).. В каждого приложения есть товар/услуга(таб5) который надо купить,сч/ф(таб6) счет на оплату(таб7).Также справочники по организациям, банкам, пользователям ... . И это 10% базы. Почти 1с Бухгалтерия .
Шеф "продвинутый пользователь", начинал проект как он говорил, с пару таблиц. Последние росли росло и их количество. Связываю их по ID.
Использую EMS SQL manager. В нем все таблицы открываются и можно редактировать. наврятли в SQL manager и 1с идет переключение компонент с неизвестным кол-вом таблиц.
Проще говоря, можно избавиться от постоянного создания Query и чрезмерного переключения между компонентами?

Добавлено:
И в мыслях не было сравнивать свою программульку с С ТАКИМИ ГИГАНТАМИ КАК 1С И EMS.
Меня интересуют принципы их работы касающиеся поднятого мной вопроса и как лучше организовать работу проекта.

Незнаю я в своих прогах делаю одну таблицу главную содержащую основные записи, далее отдельно во вкладках при переходе открываю необходимые поля для заполнения или связанный запос, итого открыто всегда 2 запоса.
В связанных запросах конечно же может быть выборка из нескольких таблиц.
И глаза куча полей не мозолит и юзеру понятна последовательность заполнения

Цитата:

Проще говоря, можно избавиться от постоянного создания Query и чрезмерного переключения между компонентами?

Избавиться можно от чего угодно. Вопрос в том, что делает пользователь при этом всем.
Счета на оплату, договора и доп. соглашения генерируются автоматически - здесь можно объединить все в один код и вероятно уменьшить кол-во запросов. Я так понимаю, вы делаете на каждый запрос по таблице и получается куча таблиц. Так ведь можно делать запросы без привязки к таблицам. Сделали запрос обработали данные и удалили запрос. А некоторые вопросы можно решить на стороне сервера за счет хранимых процедур, например, всю генерацию отчетов и договоров можно делать на стороне сервера. Базы данных postgreSQL поддерживаю хранимые процедуры. Я вам советую пересмотреть интерфейс и запросы и часть обработки данных перенести на сервер.