| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Освобождение ресурса в finally
Arinyshka © (2008-04-23 12:17:00)
Страницы: < 1 2 3 4 5 6 7 8 9 10 ... 32 33 >
Не подскажете еще один момент:
Есть процедура, выглядит примерно так
procedure TSetPayFrm.BtnAddImageClick(Sender: TObject);
var TempBitmap:TBitmap;
begin
if not(opendialog1.Execute) then exit;
try
TempBitmap := TBitmap.Create;
TempBitmap.LoadFromFile(OpenDialog1.FileName);
finally
TempBitmap.Free;
end;
end;
На освобождение TempBitmap.Free; выдает варнинг
[Warning] uSetPaymentMain.pas(313): Variable 'TempBitmap' might not have been initialized
Не смертельно, но непонятно... почему варнинг? При изменениии условия и включении всей конструкции в один блок begin..end ситуация не менялась.
Игорь Шевченко (2008-05-07 17:31:00) [101]
> Из опыта : очень плохо, когда текст скл живет в приложении.
> Скл надо держать на хранимках. Иначе будет много граблей
> при сопровождении и модификации.
А какая разница ?
ANB (2008-05-07 17:29:00) [102]
> двузвенка никогда не может быть отрешена от БД
У диасофта как раз трехзвенка. А мона сдуру и двухзвенку написать отвязанную от конкретной БД. Достаточно использовать АДО. Но я такой дурью никогда маятся не буду.
> а на серверную сторону повлияет лишь тем, что если есть
> какая то специфика, то конечно ее придется подправить...
>
Дык специфика всегда есть. мс скл от оракла синтаксисом довольно сильно отличается.
Ты попробуй, реши мою тестовую задачку. Представь, что это нужно сделать с аппсервера.
> одна из задачь трехзвенки - как раз абстракция клиентского
> проложения от какой либо БД
Трехзвенка для этих целей ничем не круче двухзвенки.
> а каким образом объем БД влияет на производительность многозвенки?
Начнут тормозить запросы к БД.
Особенно, когда запустишь отчет "По всем документам за год".
Из опыта : очень плохо, когда текст скл живет в приложении. Скл надо держать на хранимках. Иначе будет много граблей при сопровождении и модификации.
Palladin (2008-05-07 17:27:00) [103]
> Reindeer Moss Eater © (07.05.08 17:24) [548]
вообще говоря в частном случае решается конечно
и в общем тоже, но при помощи создания встроенного в приложение среднего звена :)
Reindeer Moss Eater (2008-05-07 17:24:00) [104]двузвенка никогда не может быть отрешена от БД,
да лехко. или по крайней мере иногда. но никогда - "никогда".
Игорь Шевченко (2008-05-07 17:24:00) [105]ANB (07.05.08 16:51) [542]
> надо что бы все документы проходили через единую БД, но
> при этом работало все надежно, не тормозило и не падало,
> если какой то экскаваторщик в урюпинске расхреначил федеральный
> кабель москва-владик, у спутника связи сдохла батарея, и
> ближайший резервный канал связи откроется тока через 4 часа.
> И при этом будет безбожно тормозить
> Решение : трехслойка нафиг тут не нужна. Ставим в кажной
> офисе локальный оракл (где потолще, где потоньше) и организуем
> репликацию.
> Репликацию пишем так, чтобы ботала при любом качестве связи
> и сама искала резервные каналы связи. Преимущество решения
> без трехслойки - мона скока угодно изгалятся с каналами
> связи и из типами, при этом клиентские приложения продолжают
> спокойно работать.
Я конечно сильно извиняюсь, но как тебе поможет репликация при требовании "что бы все документы проходили через единую БД" ?
Ты собираешься свои 20 терабайт на каждой локальной точке держать ?
Palladin (2008-05-07 17:14:00) [106]
> Диасофт
это который банковскими операциями рулит? он оказывается отрешеннный от БД? двузвенка никогда не может быть отрешена от БД, это нонсенс. одна из задачь трехзвенки - как раз абстракция клиентского проложения от какой либо БД, всем рулит сервер...
Palladin (2008-05-07 17:12:00) [107]
> Дальше система начнет обрастать все большим и большим количеством
> отчетов,
ооо, отчеты есть... разной сложности... много, особенно по коммуналке.... и прикинь работают... и чет никто не жалуется...
> Во. Т.е. об универсальности речь уже не идет.
речь шла о том, что смена БД никак не повлияет на работу приложений-клиентов... а на серверную сторону повлияет лишь тем, что если есть какая то специфика, то конечно ее придется подправить...
Palladin (2008-05-07 17:10:00) [108]
> ANB (07.05.08 17:08) [544]
эээ... я что то не понял... ну хотя ты меня предупреждал конечно... а каким образом объем БД влияет на производительность многозвенки?
ANB (2008-05-07 17:08:00) [109]
> если понадобится та или иная специфика работы с БД,
Во. Т.е. об универсальности речь уже не идет.
Диасофт со своей поддержкой 2-х СУБД уже вешается.
> конечно оно растет, БД коммунальных платежей за 4 года аж
> 9гб... НПА (норм.прав.акты) за 3 года аж до 2гб, за счет
> того что заказчик решил хранить приложения и документы офиса
> в базе... это самые крупные базы...
Во. А говорил, что объемов нету.
И по мере развития системы они будут расти еще быстрее.
Дальше система начнет обрастать все большим и большим количеством отчетов, которые начнут тормозить на стандартном скл.
Потом вылезут ночные техпроцессы. Когда время их выполнения превысит 12 часов, единственным правильным решением будет начать переносить их на серверную логику.
И лучше этот момент продумать сразу, пока не начали стучать по голове заказчики.
Palladin (2008-05-07 16:58:00) [110]
> ANB (07.05.08 16:24) [539]
> И ты хочешь сказать, что количество записей в таблицах расти
> не будет ?
конечно оно растет, БД коммунальных платежей за 4 года аж 9гб... НПА (норм.прав.акты) за 3 года аж до 2гб, за счет того что заказчик решил хранить приложения и документы офиса в базе... это самые крупные базы...
> А по задачке - я разве просил это выполнить обязательно
> с клиента ?
> Приведи пример скрипта, который будет одинаков и для оракла
> и для мс скл.
он не будет одинаков, как я уже сказал
> если понадобится та или иная специфика работы с БД,
ANB (2008-05-07 16:51:00) [111]
> Игорь Шевченко © (07.05.08 16:39) [541]
>
> > И озвучь, чего я не смогу сделать на оракле, чтобы понадобился
>
> > аппсервер.
>
>
> Доступ с разных концов страны
Уточняем условия :
имеем 40 офисов по России и 20 за бугром. В кажном офисе от 100 до 5 человек. В головном сидит почти 1000.
Все сидят за компами и стучат клавишами - оформляют документы и пишут письма.
Задача : надо что бы все документы проходили через единую БД, но при этом работало все надежно, не тормозило и не падало, если какой то экскаваторщик в урюпинске расхреначил федеральный кабель москва-владик, у спутника связи сдохла батарея, и ближайший резервный канал связи откроется тока через 4 часа. И при этом будет безбожно тормозить.
Так пойдет ?
Решение : трехслойка нафиг тут не нужна. Ставим в кажной офисе локальный оракл (где потолще, где потоньше) и организуем репликацию.
Репликацию пишем так, чтобы ботала при любом качестве связи и сама искала резервные каналы связи. Преимущество решения без трехслойки - мона скока угодно изгалятся с каналами связи и из типами, при этом клиентские приложения продолжают спокойно работать.
Игорь Шевченко (2008-05-07 16:39:00) [112]
> И озвучь, чего я не смогу сделать на оракле, чтобы понадобился
> аппсервер.
Доступ с разных концов страны
ANB (2008-05-07 16:26:00) [113]
> Игорь Шевченко © (07.05.08 16:17) [538]
Хорошо. Возьми сам любую знакомую предметку, которая требует для работы базу данных.
И озвучь, чего я не смогу сделать на оракле, чтобы понадобился аппсервер.
ANB (2008-05-07 16:24:00) [114]
> я чесно говоря не знаю как она конкретно называется, но
> сводится к ведению реестров, распределенный паспортный стол,
> коммунальные платежи... много еще... нормативно-правовые
> акты (этакий урезанный документо-оборот)...
> отдельно стоит область отчетности...
>
> сам назови эту область как хочешь...
Большой и толстый документооборот. Напоминает АБС.
И ты хочешь сказать, что количество записей в таблицах расти не будет ?
А по задачке - я разве просил это выполнить обязательно с клиента ?
Приведи пример скрипта, который будет одинаков и для оракла и для мс скл.
> ты не задумывался, что будучи кодером зарабатываешь больше
> чем будучи архитектором совсем не потому, что архитекторам
> меньше платят...
Задумывался. Выяснил, что архитекторам сейчас таки меньше платят. Застой на рынке ИТ.
Игорь Шевченко (2008-05-07 16:17:00) [115]ANB (07.05.08 15:52) [536]
Это все конечно хорошо, только сильно напоминает одну задачку - есть на входе текстовый файл, оформленный по неким правилам, надо его прочитать и сформировать на выходе двоичный файл, тоже по неким правилам.
Palladin (2008-05-07 15:59:00) [116]
> Надо : в одной транзакции добавить документ и к нему пару
> строк.
клиентские приложения не проводят никакой работы с БД, они работают с сущностями предоставляемыми им сервером... конкретная реализация поведения той или иной сущности и сериализация ее в БД может реализоваться на сервере в виде скриптов... если понадобится та или иная специфика работы с БД, то так и делается клиентское приложение не трогается...
> ЗЫ. Предметка так и не озвучена.
я чесно говоря не знаю как она конкретно называется, но сводится к ведению реестров, распределенный паспортный стол, коммунальные платежи... много еще... нормативно-правовые акты (этакий урезанный документо-оборот)...
отдельно стоит область отчетности...
сам назови эту область как хочешь...
> Это ты ничего пока не понял. С опытом поймешь.
куда мне... созданные проекты работают годами, а я так ничего и не понял... видимо судьба у меня такая... интересно... ты не задумывался, что будучи кодером зарабатываешь больше чем будучи архитектором совсем не потому, что архитекторам меньше платят...
на сим диалог заканчиваю, он потерял конструктивность, ты все время хочешь развести меня на померятся пиписками...
ANB (2008-05-07 15:52:00) [117]
> Мне слово "статус", "проводка", "ККМ", "РКЦ" и всякие кредиты
> с депозитами не говорят ничего.
Статус - состояние документа (тока введен, проверен, проведен)
Проводка - тоже самое как в бухгалтерии. Дебет кредит
ККМ - хреновина, которая печатает кассовые чеки под управлением компутера
РКЦ - расчетно-кассовый центр. через них проходят наши переводы из одного банка в другой. Обмен файловый.
ANB (2008-05-07 15:50:00) [118]
> Ну сам понимаешь, без трехзенки никуда :)
Дык как то без нее обходимся. Нам тока аппсерверов для полного счастья не хватает.
ЗЫ. Куда то палладин пропал. Так и не решил задачку. Наверное, задумался об архитектуре своего монстра.
Игорь Шевченко (2008-05-07 15:40:00) [119]ANB (07.05.08 15:25) [533]
> Позволять заводить документы, проталкивать их по статусам,
> печатать чеки на ККМ, отправлять и принимать документы
> из/в РКЦ.
> Проводить документы, отражая проводки и остатки на счетах.
>
> Вести учет договоров кредитов и депозитов, начислять на
> них проценты.
> Обмениваться данными с другими системами.
Ну сам понимаешь, без трехзенки никуда :) Особенно в "проталкивании".
Мне слово "статус", "проводка", "ККМ", "РКЦ" и всякие кредиты с депозитами не говорят ничего.
Количество народу 200 человек тоже ничего не говорит, если они все сидят в одном тесном помещении, то достаточно локалки, если они равномерно распределены по планете, то локалки недостаточно - на кабеле разоришься да и сигнал затухнет, пока будет из Копена в Гаген идти.
ANB (2008-05-07 15:25:00) [120]
> С картинками ?
Не. Документы, проводки, аналитика по договорам и счетам.
Позволять заводить документы, проталкивать их по статусам, печатать чеки на ККМ, отправлять и принимать документы из/в РКЦ.
Проводить документы, отражая проводки и остатки на счетах.
Вести учет договоров кредитов и депозитов, начислять на них проценты.
Обмениваться данными с другими системами.
Народу - у нас немного, не больше 200 человек, т.к. АБС используется в качестве бэк-офиса.
Основные процессы идут на сервере.
| |
