Tradução, classes ODBC do wxWidgets

Sentindo a necessidade de uma documentação mais concisa em português sobre as classes ODBC do famoso framework wxWidgets, decidi colocar a mão na massa e traduzir o documento original que pode ser encontrado no site oficial.

Note que não levei a tradução totalmente a sério pois necessitava disso o mais rápido possível e estava com bastante pressa também, o importante é esclarecer da melhor forma possível alguns parágrafos para os que não sabem inglês.

A tradução segue abaixo:

<!– @page { size: 21cm 29.7cm; margin: 2cm } P { margin-bottom: 0.21cm } TD P { margin-bottom: 0cm } H3 { margin-bottom: 0.21cm } –>A seguir é explanado uma visão geral de como usar as classes ODBC do WxWidgets, – wxDb e wxDbTable e as funções associadas a essas classes. Essas são as classes ODBC doadas pelo Remstar Internacional e são coletivamente aqui referenciados pelas classes wxODBC.

wxDb/wxDbTable wxODBC visão geral
wxODBC Por Onde Iniciar
wxODBC – Configurando seu sistema para uso com ODBC
wxODBC – Compilando
wxODBC – Passo-A-Passo Básico.
wxODBC – Problemas Conhecidos
wxODBC – Exemplo de código
Uma seleção de comandos SQL.

—————————————————————————————————-

Commit: Inserções/deleções/atualizações

Rollback: Voltar atrás / Desfazer

Datasource: (usualmente, base de dados) que contém os dados que irão ser acessados pelas classes wxODBC.

Data table: uma seção de Datasource (origem dos dados) que contém os dados em linhas e colunas.

ODBC Driver: o software middle-ware que interpreta os comandos ODBC enviados pela sua aplicação e os converte ao formato SQL esperado pelo banco de dado Alvo.

Datasource connection (conexão com a origem de dados): Um pipe aberto entre a aplicação e o driver ODBC que está conectado a um datasource alvo. Conexões ao datasource podem ter um número virtualmente ilimitado de instancias wxDbTable usando a mesma conexão (dependente do driver ODBC). Não é necessária uma conexão separada para cada tabela (a exceção é para o isolamento de commits e rollbacks em diferentes tabelas para afetar mais de uma tabela desejada. Veja a documentação da classe em wxDb::CommitTrans e wxDb::RollbackTrans.)

Rows (linhas): similar a records em banco de dados relacionais antigos, uma linha é uma coleção de uma instancia para cada coluna da tabela de dados que são todas associadas entrei si.

Colunas: campos individuais associados com cada linha da tabela de dados.

Result Set (conjunto de dados): os dados que combinam com os requerimentos especificados em uma consulta enviada ao datasource (origem de dados/banco de dados propriamente dito) Dependente de drivers, um result set, tipicamente continua na datasource (nenhum dados é transmitido pelo driver ODBC) até que o cliente instrua o driver ODBC á recupera-lo.

Cursor

Um ponteiro lógico em um result set gerado por uma consulta, indica o próximo record que será retornado ao cliente quando uma requisição para o próximo

Scrolling cursors

Scrolling refere-se ao movimento de cursors em um result set. Cursors podem sempre scrollar sequenciamente a frente em um result set (FORWARD ONLY scrolling cursors). Com cursores somente scrollaveis a frente, uma vez que uma linha em um result set foi retornado ao driver ODBC e para o cliente não existe possibilidades de ter o cursor movido para trás em um result set para obter uma linha que está antecedendo ao linha corrente de um result set. Se BACKWARD scrolling cursors são suportados por ambos: driver ODBC e base de dados, que estão sendo utilizados as funções do BACKWARD scrolling cursors podem ser utilizadas ( wxDbTable::GetPrev, wxDbTable::GetFirst, e wxDbTable::GetLast). Se a base de dados ou o driver ODBC somente suporta FORWARD scrolling cursors, seu programa logicamente deve levar isso em consideração.

Visão Geral: wxDb/wxDbTable, wxODBC

Classes: wxDb wxDbTable

As classes wxODBC são desenhadas para independencia com o Banco de Dados. Embora ambos SQL e ODBC possuirem normas que definem requerimentos mínimos que devem ser seguidos conforme as especificações, diferentes fornecedores podem implementar as coisas de maneira um pouco diferente. Um exemplo disso é a Oracle.

WxODBC – Configurando seu sistema para uso com ODBC.

Antes de estarmos apto a acessar um datasource nos devemos ter um driver ODBC instalado e configurado. Fazer isso é específico a cada sistema. Então isso não será abordado com detalhes aqui, mas aqui existem muitos detalhes para você começar.

A maioria dos fabricantes de banco de dados, provê um driver ODBC mínimo com suas base de dados, na prática, alguns desses drivers são de fato, lentos ou incompletos.

O rumor por trás disso é que a causa está ligada aos fabricantes do banco de dados que não querem que você use uma interface ODBC nesses produtos, do contrário, querem que você use a aplicação fabricada por eles para acesso aos dados.

Sobre Unix, iODBC é utilizado para implementação da API ODBC. Para compilar classes wxODBC você deve primeiro obter iODBC em http://www.iodbc.org e instala-lo. (Note: wxWidgets atualmente inclui uma versão de iODBC.) Então você deve criar um arquivo “~/.odbc.ini” (ou opcionalmente criar, para todos os usuários “/etc/odbc.ini” para acesso a todos os usuários do sistema). Esse arquivo contém as configurações para seu sistema/datasource. Abaixo é mostrada uma seção de exemplo de um arquivo odbc.ini para uso com “samples/db” programa de exemplo usando MySQL:

        [contacts]
        Trace    = Off
        TraceFile= stderr
        Driver   = /usr/local/lib/libmyodbc.so
        DSN      = contacts
        SERVER   = 192.168.1.13
        USER     = qet
        PASSWORD = 
        	     PORT     = 3306

wxODBC – compilando

O arquivo setup.h do wxWidgets contém diversas configurações em seu contexto para compilação das classes wxODBC.

wxUSE_ODBC

Isso deve ser setado para um para que o compilador possa compilar as classes wxODBC. Sem setar isso para 1 não estaremos habilitados a utilizar qualquer classe wxODBC. O padrão está setado para 0

wxODBC – Um Guia Básico Passo-a-Passo

Para usarmos as classes na aplicação, são necessárias algumas etapas básicas:

• Definindo informação da conexão com datasource

• Obtendo conexão com o datasource

• Criando definições da tabela

• Abrindo a tabela

• Usando a tabela

• Fechando a tabela

• Encerrando a conexão com o datasource

• Release the ODBC environment handle (liberando o manipulador de ambiente ODBC)

Definindo informação da conexão com datasource

Para estarmos apto a conectar no datasource através de um driver ODBC, o programa deve suprir no mínimo três campos de informação: Datasource name, ID do usuário, e string de autorização (password). O último parametro de informação é o diretório padrão que indica aonde os dados estão armazenados. É requerido por Text and dBase Drivers para ODBC.

A classe wxDbConnectInf de wxWidgets existe para tratar todos esses valores, e mais alguns outros que podem ser necessários.

O membro ‘Henv’ é o manipulador de ambiente usado para acessar a memória para uso com o driver ODBC. O uso desse membro é descrevido a seguir na sessão: “Obtendo conexão com o datasource”

O ‘Dsn’ (Datasource name) deve ser combinado exatamente com o nome usado para configurar o datasource ODBC (em ODBC Administrator (MSW somente) ou no arquivo ‘.odbc.ini’).

‘Uid’ é o id do usuário que é para ser utilizado para logar no datasource. Esse ID do usuário já deve estar criado e com direitos setados ao datasource no qual você está se conectando. O usuario que a conexão é estabelecida será determinada por quais direitos e privilégios a conexão com o datasource irá aceder para o programa possuir quando usada a conexão que essas informações de conexões forem usadas para estabelecer. Alguns datasource são sensitivos ao caso quando se trata de ID de usuário, a a implementação das classes wxODBC tentam esconder isso de você pela manipulação de qualquer dado que você passar na combinação que o datasource necessita, por isso é sempre melhor passar ‘Uid’ no modo requerido para cada datasource.

A ‘AuthStr’ é o password para o ID de usuário especificado no membro ‘Uid’. Tal como acontece com ‘Uid’, alguns datasources são sensitivos ao caso (de fato, a maioria deles). As classes wxODBC NÃO tentar gerenciar o caso de ‘AuthStr’ como todos. Isso é transmitido via texto e fora da fonte de dados, por isso você deve usar o caso sensitivo da maneira que o datasource espera.

O membro ‘defaultDir’ é usado com os datasources baseados em arquivo (e.x. Dbase, FoxPro, arquivos de texto). Ele contém o path completo para o local de onde os dados da tabela ou arquivo está localizado. Quando setado esse valor, use as barras não-invertidas ao invéz de aspas simples, escondendo as diferencas de compatibilidade entre os drivers ODBC.

Obtendo a conexão com o banco de dados:

Existem dois métodos para estabelecer uma conexão com a base de dados. Você pode criar manualmente suas instâncias wxDB e abrir a conexão ou você pode usar as funções de cache providas com as classes wxODBC para criar/manter ou deletar as conexões. Independente do método que você irá utilizar, você deve ter o objeto wxDbConnectInf preenchido . Na instância wxDbConnectInf, é provido um válido Dns (Dataname source), Uid e AuthStr (e também ‘defaultDir’ se necessário). Antes de usar isso, porém, você deve alocar o manipulador de evento para o membro ‘Henv’.

    wxDbConnectInf DbConnectInf;
    DbConnectInf.SetDsn("MyDSN");
    DbConnectInf.SetUserID("MyUserName");
    DbConnectInf.SetPassword("MyPassword");
         DbConnectInf.SetDefaultDir("");

Para alocar um manipulador de evento para uso com a conexão ODBC a classe wxDbConnectInf tem um método de banco de dados independente para criar o manipulador necessário:

 if (DbConnectInf.AllocHenv())
    {
        wxMessageBox("Unable to allocate an ODBC environment handle",
                     "DB CONNECTION ERROR", wxOK | wxICON_EXCLAMATION);
        return;
    } 
Quando a função wxDbConnectInf::AllocHenv() é chamada com sucesso, o valor verdadeiro deve ser retornado. O valor falso significa falha na alocação, e o manipulador irá ser indefinido. 
Uma pequena forma de realizar os passos acima é encapsulado dentro da longa forma do construtor de wxDbConnectInf
    wxDbConnectInf *DbConnectInf;

    DbConnectInf = new wxDbConnectInf(NULL, "MyDSN", "MyUserName",
                                                          "MyPassword", "");
Esta forma de taquigrafia de inicializar o construtor passa NULL para o manipulador de ambiente SQL, indicando ao construtor que a alocação de um manipulador deve ser feita durante a construção do objeto. Esse manipulador é também gerenciado para vida da instância do objeto wxDbConnectInf, e é liberado automaticamente após a destruição da instância.
Uma vez que a instância  wxDbConnectInf é inicializada você está pronto para se conectar a base de dados. 
Para criar manualmente conexões com o banco de dados você deve criar uma instância wxDb e então abri-la.
Deve-se criar um construtor com os seguintes parametros:
wxDb(const HENV &aHenv, bool FwdOnlyCursors=(bool)wxODBC_FWD_ONLY_CURSORS
E, no arquivo principal iniciar o mesmo dessa maneira:
  wxDb *db = new wxDb(DbConnectInf->GetHenv());
    opened = db->Open(DbConnectInf);
A primeira linha  é necessária para inicializar todos os membros da classe wxDb. A segunda linha atualmente envia o pedido ao driver ODBC para abrir uma conexão com o mesmo associada ao datasource usando os parametros passados na chamada wxDb::Open. 
A forma mais avançada de abrir conexões é usando as funções de cache de conexões que são includas com as classes wxODBC. Os mecanismos de cache proveem as mesmas funções da forma manual de se abrir uma conexão. Mas elas também gerenciam cadaconexão que tenha sido criada, re-utilizando-as e limpando-as  até quando estão fechadas, sem você precisar fazer a codificação 

Criando definições da tabela
Dados podem ser acessados nas tabelas do banco de dados diretamente por meio de várias funções da classe wxDB (veja: wxDb::GetData). Mas para tornar a vida muito mais simples, a classe wxDbTable, encapsula todas as chamadas específicas da API SQL que serão nessesárias para realizar isso, empacotando-o em uma classe intuitiva de API’s.
O primeiro no acesso dos dados em um banco de dados pela classe wxDbTable é criar uma instancia wxDbTable.

    table = new wxDbTable(db, tableName, numTableColumns, "", 
                          !wxDB_QUERY_ONLY, "");

Quando você criar a instância, você indica uma conexão prévia estabelecida com o banco de dados a ser usado no acesso a tabela, o nome da primeira tabela é a que será acessada com as tabelas do banco de dados, quantas colunas de cada linha serão retornados, o nome de cada visão da tabela que irá ser atualmente utilizada em uma consulta novamente (funciona com Oracle somente, pelo menos por enquanto) Indicar se os dados retornados são somente para fins de consulta, e finalmente o path para a tabela, caso seja diferente do caminho especificado quando conectado ao banco de dados.

Cada um dos parametros acima são descritos em detalhes na descrição da tabela wxDbTable, mas uma nota especial aqui é sobre o quinto parametro – a configuração queryOnly. Se uma instância da tabela é criada como wxDB_QUERY_ONLY, então nenhuma inserção, deleção ou upadte poderá ser feito usando essa instância de wxDbTable. Qualquer chamada a wxDb::CommitTrans ou wxDb::RollbackTrans novamente sobre a conexão com a base de dados usada pela instancia wxDbTable serão ignoradas, por esta instancia. Se a instancia de wxDbTable é criada com !

wxDB_QUERY_ONLY como mostrado acima, então todos os cursores e outras overheads (sobrecarga) associados com o primeiro estatão aptas a inserir, deletar e atualizar os dados na tabela criada, assim essas operações podem ser feitas sobre a tabela associada a essa instancia de wxDbTable.

Se a tabela for acessada por uma instancia de wxDbTable, e a tabela só será lida a partir de, e não a escrita, existe um benefício quanto a performance (não será necessário manter ou atualizar vários ‘cursors’ por conseguinte, acelerando o tempo de acesso), bem como irá poupar recursos devido ao menor número cursores sendo criado para instancia de wxDbTable, Além disso, com algumas Datasources, o número de cursores simultâneas é limitado.

Quando definimos as colunas a serem recuperadas (obtidas) pela instancia de wxDbTable, você pode especificar qualquer lugar em uma coluna de todas as colunas da tabela.

    table->SetColDefs(0, "FIRST_NAME", DB_DATA_TYPE_VARCHAR, FirstName,
                      SQL_C_WXCHAR, sizeof(FirstName), true, true);
    table->SetColDefs(1, "LAST_NAME", DB_DATA_TYPE_VARCHAR, LastName,
                      SQL_C_WXCHAR, sizeof(LastName), true, true);
Note que a definição da coluna inicia em 0 e vai até o número inferior ao número de colunas especificados quando a instancia de wxDbTable foi criada (nesse examplo, duas colunas – uma com index 0 e outra com index 1 (início 1)).

As linhas acima de código “infiltram-se” nas colunas da base de dados especificadas e nas variáveis da memória na aplicação cliente. Então quando a aplicação realiza a chamada á wxDbTable::GetNext (ou qualquer outra função que obtem data de um result set), as variáveis que são encontradas na coluna terão o valor da coluna armazenado dentro do mesmo. Veja a documentação da classe wxDbTable::SetColDefs para mais detalhes relacionados a todos os parametros dessa função.

As variáveis de memória vinculadas tem dados indefinidos até que uma chamada que recupera os dados de um result set é feita (e.x. wxDbTable::GetNext, wxDbTable::GetPrev, etc). As variaveis não são inicialidas com qualquer dado pelas classes wxODBC, e também não contem dados definidos após chamar wxDbTable::Query. Somente depois de uma chamada com sucesso é feita a uma função do tipo ::GetXxxx() que irá fazer com que as variáveis possuam dados válidos.
Isso não é necessário para definir coluna definições para colunas no qual os dados não serão retornados ao cliente. Por exemplo, se você quer consultar o banco de dados para todos os usuarios cujo primeiro nome é ‘GEORGE’, mas somente quer a lista de últimos nomes associada a essa linha(por isso, o regresso FIRST_NAME a uma coluna de cada vez quando você já sabe que é ‘GEORGE’), você teria apenas necessária para definir uma coluna acima.
Você deve ter algumas instancias wxDbTable acessando a mesma tabela usando a mesma instancia wxDb que você quiser. Não existe limites impostos pela classe neste caso. Todas as base de dados suportadas (até agora) não tem limitações em relação a isso.
Abrindo a tabela

Abrir a tabela não é feito tecnicamente com nada relacionado a database propriamente dita. Chamando wxDbTable::Open simplesmente faz a checagem se a tabela especificada existe, que o atual usuário conectado tenha ao menos privilégios de SELECT para acessar a tabela, configura os cursores requeridos, monta colunas e cursores, e constroe a instrução padrão INSERT que é utilizada quando uma nova linha é inserida na tabela (não somente em tabelas wxDB_QUERY_ONLY).

    if (!table->Open())
    {
        // An error occurred opening (setting up) the table
    }

A única razão em que uma chamada a wxDbTable::Open pareça falhar é que o usuário não tem privilégios suficientes para um SELECT na abela. Outros problemas podem ocorrer, como a incapacidade de vincular colunas, por falta de memória, qualquer erro gerado internamente por Open são logados pelo log de erro se SQL logging está ativo para as classes.

Usando a Tabela

Para usar a tabela e as definições que agora estão já configuradas, nós devemos primeiramente definir quais dados queremos no banco de dados para coletar de um result set, dizer de onde queremos obter os dados, e em que sequencia nós queremos que esses dados sejam retornados

    // a cláusula WHERE limita/especifica as linhas na tabela.
    // que serão retornadas em um result set
    table->SetWhereClause("FIRST_NAME = 'GEORGE'");

        // result set irá ser classificado em ordem alfabética ascendente nos dados 
        // na coluna 'LAST_NAME' para cada linha se o mesmo ultimo nome na 
        // tabela para duas colunas, sub-sort na coluna 'AGE'
    table->SetOrderByClause("LAST_NAME, AGE");

    // Nenhuma outra tabela (joins) são usadas para essa consulta.
        table->SetFromClause("");
As linhas acima irão ser usados para informar ao banco de dados para retornar em um result all todas as linhas na tabela cuja coluna 'FIRST_NAME' contenha o nome 'GEORGE' (note o uso requerido de aspas simples sobre uma string literal) e que o result set irá ertornar as linhas organizadas na ordem ascendente de últimos nomes (acescendente é padrão, e pode ser escondida com a keywork “DESC” para o banco de dados que suporta-o - “LAST_NAME DESC”).

Especificando cláusula WHERE em branco irá resultar em um result set contendo todas linhas do banco de dados.
Especificando a cláusula ORDERBY vazia, significa que o banco de dados irá retortar o result set (conjunto de resultados) na sequencia que o mesmo encontrar das linhas que combinam com o critério da seleção. Qual essa sequencia é possível no entanto difícil de determinar. Tipicamente depende do index que o banco de dados usou para encontrar as linhas com a combinação WHERE.
Cuidado – que dependem da fonte de dados para retornar os dados em uma determinada seqüência, quando você não tiver fornecido uma cláusula orderby acabará por causar um problema para o seu programa. Bases de dados pode ser sintonizado para ser CUSTO-based, a velocidade de base, ou alguma outra base de como fica o conjunto de resultados. Em suma, se você precisa de seu grupo de resultados retornados em uma seqüência específica, peça para ele dessa forma, proporcionando uma cláusula orderby.
Invocando o banco de dados a retornar os dados em uma certa sequencia quando você não proveu a cláusula ORDERBY irá eventualmente causar um problema em seu programa. Banco de dados podem ser configurados para COST-based, SPEED-based, ou outras bases para como ela irá obter os result set. Em resumo, se você precisa de seu rsult set retornado em uma sequencia específica, peça para ele dessa forma, proporcionando uma cláusula ORDERBY.
Usando uma cláusula ORDERBY pode ter uma performance de sucesso, como o banco de dados deve organizar os items antes de setar as váriaveis result set ao cliente. Criando eficientes indexes que causam os dados serem encontrados na ordem correta na sequencia ORDERBY podem ter uma grande benefício de performance. Também na grande maioria dos casos, o banco de dados estará apto a organizar os ‘records’ mais rapidamente do que a sua aplicação pode ler (desorganizadamente) e então classifica-los. Deixe que o banco de dados faça esse trabalho para você!
Note que no exemplo acima, a coluna que não é incluida nas colunas cujos dados relacionados (‘AGE’) irão ser usados para sub-ordenar o result set.

A cláusula FROM nesse exemplo é omitida,
The FROM clause in this example is blanked, as we are not going to be performing any table joins with this simple query. When the FROM clause is blank, it is assumed that all columns referenced are coming from the default table for the wxDbTable instance.

After the selection criteria have been specified, the program can now ask the datasource to perform the search and create a result set that can be retrieved:

    // Instruct the datasource to perform a query based on the 
    // criteria specified above in the where/orderBy/from clauses.
    if (!table->Query())
    {
        // Um erro ocorreu enquando fazia uma consulta.
    }
Tipicamente, quando um erro ocorre quando chamamos wxDbTable::Query, pode ser um problema de sintax na cláusula WHERE que foi especificada. A SQL exata (especifico do banco de dados) a razão para a causa dessa falha de wxDbTable::Query (e todas as outras operações sob o banco de dados podem ser encontrados lendo a tabela de conexão do banco de dados 'errorList[]' que é um membro-array para armazenamento de texto desses erros. 

Quando wxDbTable::Query retornar verdadeiro, o banco de dados foi abilitado com sucesso a completar as requisições de pesquisa usando os critérios passados. Isso não significa qualquer das linhas do result set, isso somente significa que a consulta foi um sucesso.

IMPORTANTE: o resultado criado pela chamada de wxDbTable::Query pode pegar de duas formas. É um snapshot dos dados no momento exato em que o banco de dados determinou os critérios da combinação da busca, ou é um ponteiro para linha que foi encontrada no critério de seleção. Que tipo de comportamento é dependente de dados. Se é um instantâneo, os dados podem ter mudado desde que o conjunto de resultado foi construído, por isso tome cuidado se sua fonte de dados e utiliza chamadas instantâneas wxDbTable::Refresh. A maioria das grandes marcas não usam bases instantâneas, mas é importante mencionar, que seu aplicativo poderá manipulá-lo corretamente, se sua fonte de dados não.

Para recuperar os dados, uma rotina de coleta de dados deve ser utilizado para solicitar uma linha a partir do conjunto de resultados (result set) e armazenar esses dados do result set nas variáveis vinculadas/armazenadas na memória.

Após wxDbTable::Query tenha completo com sucesso, o padrão/atual cursor será colocado para que ele esteja apontando justamente para o primeiro ‘record’ em um result set, se o resultado de set é vazio (nenhuma linha é combinada no critério), então qualquer chamada para requisição de dados do result set irá retornar falso.

    wxString msg;

    while (table->GetNext())
    {
        msg.Printf("Row #%lu -- First Name : %s  Last Name is %s",
                   table->GetRowNum(), FirstName, LastName);
        wxMessageBox(msg, "Data", wxOK | wxICON_INFORMATION, NULL);
    }

O código de exemplo acima irá ler o próximo ‘record’ no result set repetidamente até que o final do result set seja atingido. A primeira vez que wxDbTable::GetNext é chamado corretamente após uma chamada com sucesso a wxDbTable::Query, atualmente retornará o primeiro ‘record’ em um result set.

Quando wxDbTable::GetNext é chamado e não existem linhas restante em um result set após a atual posição do cursor, wxDbTable::GetNext (assim como todas as outras funções wxDbTable::GetXxxxx()) irá retornar falso.

Fechando a tabela

Quando o programa é terminado usando uma instancia wxDbTable, é simples como deletar o ponteiro da tabela (ou se declarado estaticamente, obter a variável fora de escopo). Tipicamente o destrutor irá obter todos os requisitos necessários para fazer a limpeza da instancia de wxDbTable

  if (table)
    {
        delete table;
        table = NULL;
    }

Deletando uma instancia wxDbTable liberará todos os seus cursores, deleta as definições da coluna e libera o manipulador de ambiente SQL usado pela tabela (mas não o manipulador de ambiente utilizado pela conexão com o banco de dados, que é a instancia que wxDbTable estava usando.).
Fechando a conexão com o banco de dados
Após todas as tabelas que estavam sendo usadas com a conexão com o banco de dados serem fechadas (isso pode ser verificado chamando wxDb::GetTableCount e checando se o mesmo retorna 0), então você deve fechar conexão com a origem de dados (datasource / banco de dados) O método de fazer isso é dependente de qual método está sendo usado atualmente – non-caching ou caching para obter a conexão com o banco de dados.
Se a conexão com o banco de dados foi criada manualmente (non-cached), fechar a conexão é feita através disso:

    if (db)
    {
        db->Close();
        delete db;
        db = NULL;
    }
Se o programa usou a função wxDbGetConnection para obter uma conexão com o banco de dados, o seguinte código deve ser usado para liberar a conexão(es):
    if (db)
    {
        wxDbFreeConnection(db);
        db = NULL;
    }
Note que o código acima somente libera a conexão que pode ser re-utilizada na próxima chamada á wxDbGetConnection. Para realmente eliminar a conexão, liberando todos os recursos (que não seja o manipulador do ambiente), faça o seguinte:
    wxDbCloseConnections();

Liberando o manipulador de ambiente ODBC

Uma vez que todas as conexões que usam o manipulador de ambiente ODBC (nesse exemplo ela é armazenada em “DbConnectInf.Henv”) tenham sido fechadas, então é seguro liberar o manipulador de ambiente:

    DbConnectInf->FreeHenv();
Ou se a longa forma do construtor foi usado e o construtor foi habilitado a alocar isso no nosso manipulador de ambiente SQL, deixando o escopo ou destrução dde wxDbConnectInf, irá liberar o manipulador automaticamente:
    delete DbConnectInf;

UNICODE com classes wxODBC

Na versão 2.6 do wxWidgets, as classes wxODBC, agora tem suporte completo a compilação e uso de classes em uma construção unicode do wxWidgets. Assumindo o compilador e o OS no qual o programa irá ser compilado está rodando ou pode rodar no modo unicode.

Em modo unicode os tipo das colunas nas strings assumiram SQL_C_WXCHAR ao invés de SQL_C_CHAR ou SQL_C_WCHAR.

* Essa tradução foi feita pelo mantenedor do Blog com a espectativa de que possa de alguma forma ajudar o leitor.