Неверная ссылка к объекту уже освобождена
я решил запрос таким образом
SELECT
ca.ID, ca.[Name]
FROM [Emp2]
CROSS APPLY (
Values
('ID' , cast(ID as varchar)),
('[Name]' , Name)
) as CA (ID, Name)
вывод выглядит как
ID Name
------ --------------------------------------------------
ID 1
[Name] Joy
ID 2
[Name] jean
ID 4
[Name] paul
6 ответов
Если Вы используете FastMM4 в качестве своего Диспетчера памяти, можно проверить, что классом не является TFreeObject.
Или в более стандартном случае используйте стандартную программу, которая проверит, что Ваш объект - то, что он говорит, что это путем проверки класса VMT.
Были такие функции ValidateObj, зависающие вокруг в течение некоторого времени (Ray Lischner и Hallvard Vassbotn: http://hallvards.blogspot.com/2004/06/hack-6checking-for-valid-object.html)
Вот другой:
function ValidateObj(Obj: TObject): Pointer;
// see { Virtual method table entries } in System.pas
begin
Result := Obj;
if Assigned(Result) then
try
if Pointer(PPointer(Obj)^) <> Pointer(Pointer(Cardinal(PPointer(Obj)^) + Cardinal(vmtSelfPtr))^) then
// object not valid anymore
Result := nil;
except
Result := nil;
end;
end;
Обновление: Немного осторожности... Вышеупомянутая функция гарантирует, что результатом является или ноль или допустимое не нулевой Объект. Это не гарантирует, что Obj все еще, что Вы думаете, что это, в случае, если, где Диспетчер памяти уже перераспределил ту ранее освобожденную память.
Нет. Если Вы не будете использовать что-то как подсчет ссылок или сборщик "мусора", чтобы удостовериться, что никакой объект не будет освобожден, прежде чем у них будут нулевые ссылки.
Delphi может сделать подсчет ссылок для Вас при использовании интерфейсов. Конечно, Delphi для .NET имеет gargage коллектор.
Как упомянуто Вы могли использовать knowledege Delphi или внутренностей диспетчера памяти для проверки на допустимые указатели или объекты, но они не единственные, которые могут дать Вам подсказки. Таким образом, Вы не можете покрыть все указатели даже теми методами. И также существует шанс, что Ваш указатель, оказывается, допустим снова, но данный кому-то еще. Таким образом, это не указатель, Вы ищете. Ваш дизайн не должен полагаться на них. Используйте инструмент для обнаружения любых ссылочных ошибок, которые Вы делаете.
Стандарт, нет...
Вот почему компоненты VCL могут зарегистрировать себя, чтобы быть уведомленными относительно разрушения объекта, так, чтобы они могли удалить ссылку оттуда внутренний список компонентов или просто сбросить их свойство.
Таким образом, если Вы хотели бы удостовериться, что у Вас нет недопустимых ссылок их, две опции:
- Реализуйте обработчик уведомлений о разрушении, на который может подписаться каждый класс.
- Исправьте свой код способом, что ссылки не распространены вокруг канавки другой объект. Вы могли, например, только обеспечить доступ к ссылке через свойство другого объекта. И вместо того, чтобы копировать ссылку на частное поле Вы получаете доступ к свойству другого объекта.
Как другие сказали, никакой категорический путь, но если Вы будете управлять владением хорошо, то затем стандартная программа FreeAndNil гарантирует, что Ваша переменная является нолем, если это ни на что не указывает.
Это обычно - не хорошая идея проверить, что ссылка действительна так или иначе. Если ссылка не будет действительна, то Ваша программа откажет в месте, где она использует недопустимую ссылку. Иначе недопустимая ссылка могла бы выжить дольше, и отладка становится более трудной.
Вот некоторые ссылки на то, почему лучше отказать на недопустимой ссылке. (Они говорят об указателях в Win32, но идеи все еще релевантны):
К сожалению, нет никакого пути к 100%-й гарантии, что указатель на что-либо все еще допустим, кроме путем отвратительного написания правильного кода.