| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / 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 ситуация не менялась.
ANB (2008-05-16 15:23:00) [1]
> Palladin © (16.05.08 12:14) [651]
У тебя аппсервер знает. Через скрипты.
Мне больше нравится механизм, что знать должен только сам сервер СУБД.
А клиент только должен вызывать хранимки. Причем это тоже должно управляться сервером.
Короче, моя идея отличается от твоей в том, что бизнес слой и метаданные я хочу разместить прямо на сервере СУБД, а ты разместил это все на аппсервере.
Palladin (2008-05-16 12:14:00) [2]
> ANB (15.05.08 16:52) [650]
но ведь кто-то же должен... кто же...
ANB (2008-05-15 16:52:00) [3]
> И правильно делает, что не знает.
Дык я разве против ?
Я считаю, что клиент и без аппсервера ничего про структуру базы знать не должен.
Игорь Шевченко (2008-05-15 11:40:00) [4]ANB (15.05.08 11:31) [648
> Ну дык у палладина "тонкий" клиент и про базу и ее структуру
> вообще ничего не знает.
И правильно делает, что не знает. Ты, когда на сайт заходишь, не интересуешься же, на чем его движок написан, оно тебе главное, чтобы html верно формировался и отображался. У клиентов аппсервера примерно то же самое.
ANB (2008-05-15 11:31:00) [5]
> Было бы замечательно, если бы ты сразу указывал, что ты
> имеешь в виду
Ну дык у палладина "тонкий" клиент и про базу и ее структуру вообще ничего не знает.
Кстати, хорошая идея. Я тоже собираю материал, чтобы занятся реализацией. Только камней подводных много.
Игорь Шевченко (2008-05-14 15:19:00) [6]ANB (14.05.08 15:07) [646]
Про Аппсервер я тоже написал.
"В контексте AppServer-а, в зависимости от СУБД и может возникнуть нужда обрабатывать "записи" поодиночке, а может и не возникнуть, если, опять же, сущности могут безболезненно путешествовать между СУБД и сервером приложений."
> Я не имел ввиду под словом "приложение" клиента. Я имел
> ввиду сам аппсервер. Или он уже не приложение ?
Было бы замечательно, если бы ты сразу указывал, что ты имеешь в виду
ANB (2008-05-14 15:07:00) [7]
> В конктесте приложения (того, которое общается с AppServer-
> ом)
Я не имел ввиду под словом "приложение" клиента. Я имел ввиду сам аппсервер. Или он уже не приложение ?
Игорь Шевченко (2008-05-14 14:46:00) [8]ANB (14.05.08 13:33) [640]
> Я просил изобразить, как в контексте твоего приложения,
> ты получаешь ID записи после/перед вставкой, чтобы потом
> использовать его дальше (например, для вставки дочерней
> записи).
В конктесте приложения (того, которое общается с AppServer-ом) нет нужды знать про какие-то ID, какие-то дочерние записи и т.п.
В контексте приложения есть нужда знать про сущности предметной области целиком (или про html-странички)
В контексте AppServer-а, в зависимости от СУБД и может возникнуть нужда обрабатывать "записи" поодиночке, а может и не возникнуть, если, опять же, сущности могут безболезненно путешествовать между СУБД и сервером приложений.
Игорь Шевченко (2008-05-14 14:43:00) [9]ANB (14.05.08 13:13) [638]
> каким сервером ? СУБД или приложений.
СУБД очевидно, так как понятие ID записи имеет смысл только при общении с базой данных, нес па ?
Palladin (2008-05-14 13:52:00) [10]
> ANB (14.05.08 13:50) [642]
с твоими религиозными убеждениями я спорить уже давно перестал...
ANB (2008-05-14 13:50:00) [11]
> в случае неопределенности с СУБД никто не будет в зравом
> уме использовать какие либо конкретные возможности какой
> либо конкретной СУБД...
В случае неопределенности с СУБД никто в здравом умене возьмется разрабатывать приложение, т.к. этот вопрос должен быть решен еще на стадии планирования. Т.к. даже архитектура приложения может иметь из-за этого различия. Да и личность архитектора от этого зависит.
Palladin (2008-05-14 13:40:00) [12]
> А вот зачем использовать костыли при наличии нормальных
> серверов с генераторами ?
ну насчет, костыли ли это, это еще спорный вопрос, а вот наличе нормальных серверов с генераторами это из другой темы... из темы совместимости всех этих серверов с генераторами между собой...
нужно, станут использовать конкретные специфики конкретных серверов, это не запрещается, если заказчик не предполагает никуда уходить с mssql или с oracla...
в случае неопределенности с СУБД никто не будет в зравом уме использовать какие либо конкретные возможности какой либо конкретной СУБД...
ANB (2008-05-14 13:33:00) [13]
> обождите, ты мне задачу давал с чем? именно в этом был подвох
> то, в PK поле обладающим св-вом identity/autoincrement,
> а иначе задача твоя изюминкой никакой не обладает и никаких
> нюансов нет...
>
> ты дал условия, я к этим условиям приспособил PS... эти
> нюансы в структуре БД, в принципе допустимы, в контексте
> аппсервера, но не рекомендуемы...
Я просил изобразить, как в контексте твоего приложения, ты получаешь ID записи после/перед вставкой, чтобы потом использовать его дальше (например, для вставки дочерней записи).
В случае использования автоинкремента эта задача с использованием только SQL-92 не решается. Во всяком случае, корректно.
Однако, выясняется, что генерацией ключей занимается не СУБД, а аппсервер.
Гы. Ну, когда я писал на клиппере, у меня тоже ИД генерились на клиенте, но там просто не было другого способа.
А вот зачем использовать костыли при наличии нормальных серверов с генераторами ?
Palladin (2008-05-14 13:19:00) [14]
> ANB (14.05.08 13:13) [638]
обождите, ты мне задачу давал с чем? именно в этом был подвох то, в PK поле обладающим св-вом identity/autoincrement, а иначе задача твоя изюминкой никакой не обладает и никаких нюансов нет...
ты дал условия, я к этим условиям приспособил PS... эти нюансы в структуре БД, в принципе допустимы, в контексте аппсервера, но не рекомендуемы...
ANB (2008-05-14 13:13:00) [15]
> Промеж клиентом и сервером, скорее всего.
каким сервером ? СУБД или приложений.
> Я не припоминаю, где эта "проблема" ставила его "в тупик"
А ответа так и не было. А тот, что был - был с использованием T-SQL.
А сейчас выясняется, что все ключи генерятся на аппсервере.
MsGuns (2008-05-14 12:20:00) [16]>ANB (14.05.08 09:51) [630]
> >Самая простая проблема - получить ID только что сгенеренной
>> записи ставит тебя в тупик.
>> Где это, что-то не припоминаю
>Узнать искусственный первичный ключ записи при вставке для того, чтобы использовать его во вставке дочерних записей.
Я не припоминаю, где эта "проблема" ставила его "в тупик"
Игорь Шевченко (2008-05-14 12:19:00) [17]ANB (14.05.08 11:33) [632]
> Куда передается ?
Промеж клиентом и сервером, скорее всего.
Palladin (2008-05-14 12:08:00) [18]и не гуид, обыкновенный int, без свойств identity/autoincrement, он не СУБД генерируется...
ANB (2008-05-14 12:01:00) [19]
> PK поле в бд - не счетчик...
Гуид что ли ?
Palladin (2008-05-14 11:38:00) [20]
> ANB
если ты задался вопросом, как же я получаю значение счетчика в рамках SQL-92, то расскажу тебе страшную тайну, PK поле в бд - не счетчик...
| |
