C++, “невозможное” поведение

У вас есть локальный AuthDB, который имеет значение NULL и скрывает ваш глобальный?

(Я ожидал, что отладчик в этом случае правильно покажет вам локальный ... но с Снижение качества VS, я бы не стал на это полагаться)

Я бы изменил код на:

_ASSERTE(AuthDb);
SingleResult sr(AuthDb, format(...));

....

struct SingleResult : public BaseResult
{    
   SingleResult(Database *db, const boost::format& query)  
  { 
    _ASSERTE(db);
    _ExecuteQuery(db, query.str()); 
  }
}

И следил за дизассемблированием в отладчике.

Ну, я не уверен, какие классы / функции вы используете здесь, но с первого взгляда, не должно быть:

SingleResult sr(AuthDb, format("SELECT Id, Access, Flags, SessionKey, RealmSplitPreference FROM accounts WHERE Name = '%s'", Escaped(account_name)));

вместо:

SingleResult sr(AuthDb, format("SELECT Id, Access, Flags, SessionKey, RealmSplitPreference FROM accounts WHERE Name = '%s'") % Escaped(account_name));

Мне кажется, вы помещаете модуль Escaped (account_name) вместо того, чтобы передавать его в качестве аргумента для форматирования. Однако я мог просто запутаться.

Майк

Одна из возможностей заключается в том, что на втором снимке экрана отладчик остановлен на очень высокой точке начало функции до того, как стек был изменен, поэтому расположение переменных неверно. Вы также можете быть после завершения функции, когда стек уже снят. Я видел подобные вещи раньше.

Разверните эту функцию до многострочной функции, чтобы она выглядела так:

struct SingleResult : public BaseResult
{
    SingleResult(Database *db, const boost::format& query)  
    { 
        _ExecuteQuery(db, query.str()); 
    }
}

... и посмотрите, по-прежнему ли она показывает db как null, когда у вас остановлен отладчик в строке _ExecuteQuery.

до того, как стек был изменен, и поэтому расположение переменных неверно. Вы также можете быть после завершения функции, когда стек уже снят. Я видел подобные вещи раньше.

Разверните эту функцию, сделав ее многострочной, чтобы она выглядела так:

struct SingleResult : public BaseResult
{
    SingleResult(Database *db, const boost::format& query)  
    { 
        _ExecuteQuery(db, query.str()); 
    }
}

... и посмотрите, по-прежнему ли она показывает db как null, когда у вас остановлен отладчик в строке _ExecuteQuery.

до того, как стек был изменен, и поэтому расположение переменных неверно. Вы также можете быть после завершения функции, когда стек уже снят. Я видел подобные вещи раньше.

Разверните эту функцию, сделав ее многострочной, чтобы она выглядела так:

struct SingleResult : public BaseResult
{
    SingleResult(Database *db, const boost::format& query)  
    { 
        _ExecuteQuery(db, query.str()); 
    }
}

... и посмотрите, по-прежнему ли она показывает db как null, когда у вас остановлен отладчик в строке _ExecuteQuery.

Другая возможность - вы могли наблюдать перезапись памяти из-за какого-то дикого указателя.

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

Скорее всего, в вашей программе есть ошибка где-то еще. Я предлагаю вам найти проблему, посмотрев в другом месте вашего кода.

Поскольку вы просили дать другие советы и рекомендации по управлению DBML ...

Когда файлы DBML обновляются из базы данных, существуют определенные параметры схемы, которые они не улавливают, например, значения столбца по умолчанию, вынуждая вас вручную изменить настройку. Это может привести к потере часов каждый раз, когда вы обновляете DBML, не осознавая или не запоминая, где вам нужно внести ручные настройки, и ваш код начинает давать сбой.

Чтобы предотвратить это, можно написать модульный тест, который использует отражение для проверьте метаданные LINQ для этих (ручных) настроек. Если тест не проходит, выдается описательное сообщение об ошибке, инструктирующее пользователя внести правильные изменения в свойства столбца. Это не идеальное решение и может быть неудобно, если у вас много ручных настроек, но если бы я отлаживал это, я бы посмотрел на ассемблер, чтобы увидеть, что происходит. Возможно, вам потребуется лучше понять соглашение о вызовах вашей платформы (то есть, как передаются аргументы, в стеке, в регистрах и т. Д.), Чтобы устранить эту проблему.