| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / 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 ситуация не менялась.
Palladin (2008-05-07 18:15:00) [81]если ты прямо хочешь так увидеть PS скрипт твое решение реализующий, то покажи как идет работа с транзакциями в оракле (я plsql не знаю) и я напишу тебе
Palladin (2008-05-07 18:08:00) [82]
> 1. Скрипт хранится просто в виде текста ?
да конечно
> 2. Кто генерит конечный скл ? Вумные слова "сериализация
> объекта" мне понятны, но не отвечают на вопрос
в случае скриптовой, то человек конечно )
> 3. Какой скл сгенерит твой паскаль скрипт по моей задачке
> ? Тем более наверняка она у тебя и так решается.
паскаль ничего не сгенерит, блин, человек пишущий скрипт его сегенерит, причем в отдельном файле сохранить может, и из PS скрипта его исполнить...
> 4. Кто у тебя проставляет хинты запросам, если поехал план
> выполнения запроса (фуллскан вместо индекс ранж скана или
> наборот) и нужно его вернуть на место или улучшить из-за
> выявившихся тормозов ?
если это имеется ввиду комментарии инструмента от оракл на подобие query analizer'а, то извини ADO эти комментарии не предоставляет...
ANB (2008-05-07 18:07:00) [83]
> помоему я уже достаточно озвучил, что твоя задача не является
> задачей, но лишь нюанс...
А что в ней непонятного ?
ANB (2008-05-07 18:05:00) [84]
> Palladin © (07.05.08 17:59) [565]
1. Скрипт хранится просто в виде текста ?
2. Кто генерит конечный скл ? Вумные слова "сериализация объекта" мне понятны, но не отвечают на вопрос.
3. Какой скл сгенерит твой паскаль скрипт по моей задачке ? Тем более наверняка она у тебя и так решается.
4. Кто у тебя проставляет хинты запросам, если поехал план выполнения запроса (фуллскан вместо индекс ранж скана или наборот) и нужно его вернуть на место или улучшить из-за выявившихся тормозов ?
Palladin (2008-05-07 18:02:00) [85]а.. ты все про свою транзакцию... :) помоему я уже достаточно озвучил, что твоя задача не является задачей, но лишь нюанс...
Palladin (2008-05-07 18:01:00) [86]в скрипте можно создавать сколь угодно объекты TADOQuery и работать с ними на всех правах, сейчас конечно придет Николай наверное, но я могу его заверить, что все объекты TADOQuery используются только во благо программинга )
Palladin (2008-05-07 18:01:00) [87]
> ANB (07.05.08 17:58) [564]
сейчас гляну
Palladin (2008-05-07 17:59:00) [88]
> ANB (07.05.08 17:56) [562]
Pascal Script'у от аппсервера передается объект соединения и данные поступившие от клиента и в синтаксисе PS реализуются необходимые действия для сериализации объекта. В случае смены БД, изменяется скрипт, сервер остается нетронутым.
вопросы
ANB (2008-05-07 17:58:00) [89]
> ANB (07.05.08 14:32) [531]
Вот моя задачка. Палладин - ты можешь ее решить ?
Пусть будет паскалеподобный скрипт.
ANB (2008-05-07 17:56:00) [90]
> отченость реализованна полностью на серверных скриптах (это
> не SQL скрипты, это Pascal Script'ы),
> либо если лучше все таки отработать со спецификой БД, то
> пишется скрипт с синтаксисом Pascal'я, который призван отработать
> звеном между БД
А скл то кто генерит ? СУБД паскаль не понимает.
ANB (2008-05-07 17:56:00) [91]
> Reindeer Moss Eater © (07.05.08 17:55) [561]
> а не подеретесь
А почти подрались уже :)
Reindeer Moss Eater (2008-05-07 17:55:00) [92]а не подеретесь
ANB (2008-05-07 17:51:00) [93]
> Во-первых, терминальный доступ - это та самая многозвенка
> о который ты говоришь (тонким клиентом выступает Terminal
> Services Client), во-вторых, я не совсем понимаю, каким
> образом поможет терминальный доступ при локальных базах,
> в-третьих, я не до конца понял с репликацией - что куда
> реплицируется через поиск резервных каналов связи и т.п.
> ?
1. Терминал и репликация - 2 разных решения.
С терминалом - уел. Пусть будет нужна трехслойка. Хотя аппсервер здесь тоже может быть тонким и бизнес логику в него пихать смысла нету.
С другой стороны, при отсутствии связи вообще, удаленный офис не сможет работать совсем.
Репликация - процесс обмена данными между отдельными серверами. Филиалы все свои документы отправляют в центральный офис. Сами получают тока нужные им документы.
Поиск резервных каналов связи : пишется специальное приложение, которое занимается только транспортом данных от сервера к серверу.
Оно должно уметь находить запасные рабочие каналы связи при отказе основных. Есно, эти запасные каналы связи сначала надо организовать, а в приложение засунуть из параметры и научить его работать с ними.
Такая штука была реализована в "МВ офисная техника" и работала довольно продуктивно.
При использовании репликации офисы смогут ограниченно работать даже при полном отсутствии связи с центром.
Palladin (2008-05-07 17:50:00) [94]
> ANB (07.05.08 17:42) [558]
1. ты тему разности производительности в случае многозвенности и двузвенности не открыл
2. ты перешел на тему отчетности, отченость реализованна полностью на серверных скриптах (это не SQL скрипты, это Pascal Script'ы), это твоя любимая двухзвенность, клиенту аппсервера передается лишь данные о создании отчета и в итоге сам созданных файл
3. при работе не с отчетом, а с сущностью, я уже сказал либо используется подход встроенной совместимости с SQL-92, либо если лучше все таки отработать со спецификой БД, то пишется скрипт с синтаксисом Pascal'я, который призван отработать звеном между БД и приложением клиента...
вопросы
ANB (2008-05-07 17:42:00) [95]
> А какая разница ?
В хранимках сразу видны ошибки в тексте запроса. На этапе компиляции. А при хранении запроса в приложении ошибки выявятся тока на тестировании при входе в эту ветку.
> запрос он и есть запрос, и его производительность от СУБД
> зависит, а не от многозвенности приложения...
Производительность запроса от его текста и размера таблиц намного больше зависит, чем от субд. На тестировании мс скл и оракл на средних обьемах ноздря в ноздрю практически по скорости идут. А вот метода оптимизации в них - разная по синтаксису.
> > Ты попробуй, реши мою тестовую задачку.
>
> какую? про xml чтоли? условия плиз исполнения, где файл
> лежит, кто чего получает..
Про добавление записей в две таблички при их мастер-детал связи.
> а вот тут батенька, я тебя жестоко обламаю, в приложении
> клиентском нет ни одного SQL скрипта
А аппсервер твой - это не приложение ? Где я писал, что в клиентском ?
Игорь Шевченко (2008-05-07 17:35:00) [96]ANB (07.05.08 17:31) [552]
> Зачем ? На кажной точке - тока нужные ей документы.
Тогда это несовместимо с требованием "что бы все документы проходили через единую БД" или ты под требованием понимаешь одно, а озвучиваешь другое.
> А уж если нужно кажный раз лазить в центральную БД, то с
> этим терминальный доступ справится.
Во-первых, терминальный доступ - это та самая многозвенка о который ты говоришь (тонким клиентом выступает Terminal Services Client), во-вторых, я не совсем понимаю, каким образом поможет терминальный доступ при локальных базах, в-третьих, я не до конца понял с репликацией - что куда реплицируется через поиск резервных каналов связи и т.п. ?
Palladin (2008-05-07 17:35:00) [97]
> Достаточно написать оболочку над стандартными компонентами,
> которые будут тягать текст запроса в зависимости от типа
> сервера.
чего чего простите делать с текстом запроса?
ANB (2008-05-07 17:33:00) [98]
> и в общем тоже, но при помощи создания встроенного в приложение
> среднего звена :)
Достаточно написать оболочку над стандартными компонентами, которые будут тягать текст запроса в зависимости от типа сервера.
Это уж никак не средний слой.
Но идея все равно хреновая, что в случае с трехслойкой, что в случае с двухслойкой.
Palladin (2008-05-07 17:33:00) [99]
> Начнут тормозить запросы к БД.
> Особенно, когда запустишь отчет "По всем документам за год".
о как... так а это, а чего вдруг двузвенка то не будет тормозить? каким волшебным свойством она обладает то? запрос он и есть запрос, и его производительность от СУБД зависит, а не от многозвенности приложения...
> У диасофта как раз трехзвенка
честно сказать не нравится он мне... мне кажется аффтары перекурили всякой гадости...
> Ты попробуй, реши мою тестовую задачку.
какую? про xml чтоли? условия плиз исполнения, где файл лежит, кто чего получает..
> очень плохо, когда текст скл живет в приложении
а вот тут батенька, я тебя жестоко обламаю, в приложении клиентском нет ни одного SQL скрипта
ANB (2008-05-07 17:31:00) [100]
> Ты собираешься свои 20 терабайт на каждой локальной точке
> держать ?
Зачем ? На кажной точке - тока нужные ей документы.
А уж если нужно кажный раз лазить в центральную БД, то с этим терминальный доступ справится.
| |
