Luisão

Acho que esse problema do erro não ser tratado pelo SQLErrorNo() é somente na hora da conexão, não é ? O que eu fiz aqui foi o seguinte: eu tenho uma rotina para tratar os erros do sistema que dá a possibilidade de visualizar LOG e enviar E-Mail. Eu coloquei então nessa rotina para verificar se SQLERRORMSG() está vazio; Se estiver foi erro do FiveWin mesmo (variável que não existe, Alias não aberto, etc...). Agora, se SQLERRORMSG() não está vazio, então faço o tratamento com base no erro que o MySQL retornou. Isso funciona para erro na conexão, comandos errados, Timeout, etc...

O que eu quero dizer é que se não foi seguida uma regra na gravação do campo, não tem como você criar uma regra para a leitura pois o conteúdo pode ter sido gravado de N maneiras diferentes. Por isso que eu acho que agora o que mais conta é a análise do Marcio para o seu próprio problema, já que citamos diversas maneiras de (tentar) resolvê-lo.

Então... se for ficar analisando assim: "Mas e se o campo estiver assim, ou se tiver desse outro jeito, ou daquele jeito..." nunca você terá um regra válida para todo caso. O aconselhável então é usar esses diversos métodos citados até agora para que o Marcio tire o melhor proveito. Se não tiver vírgula, use SUBSTR( cEnde, RAt(" ", cEnde), Len(cEnde) ) Se tiver vírgula, use SUBSTR( cEnde, RAt(",", cEnde), Len(cEnde) ) e assim por diante... Agora vai do Marcio escolher a melhor maneira e adaptar do modo que ele achar mais conveniente e funcional para ele... Como o Eder disse, eu também testei o que postei e para a maioria dos casos é para funcionar...

Tente assim: id=code>id=code>

Marllon, obrigado pela dica... Quando eu disse que o MySQL "gerencia" os índices internamente, quis dizer que não precisamos por exemplo para procurar um certo registro usar um SET ORDER TO e DBSEEK como nos comandos nativos do Clipper... Passamos apenas a cláusula WHERE no comando sem especificar indices nem nada e ele se encarrega de utilizar os melhores índices para a pesquisa... Quanto ao desempenho de se criar um índice para cada coluna, na época que estava analisando como ficaria a criação dos índices, achei que fosse a melhor solução para o momento e resolveu muito bem minha necessidade. Mas como você mesmo disse, com o tempo e com o aumento no volume de dados isso pode se tornar menos eficiente, mas por enquanto, a performance está muito boa até mesmo para tabelas muito grandes (+700.000 registros) Mas é assim que funciona, trocando informações, todos melhoramos!

Para excluir um índice: ALTER TABLE nome_tabela DROP INDEX nome_indice id=code>id=code>Caso o índice não exista, a mensagem será retornada: Can't DROP 'nome_indice' ; check that column/key exists

Bom, acredito (e acho que li em algum lugar) que o MySQL gerencie os índices internamente para obter os melhores resultados. Por exemplo, nos sistemas que usam MySQL aqui, ao se fazer ORDER BY ou SELECTs usando a cláusula WHERE, sem estar com os campos indexados, tais querys demoravam séculos... O que eu fiz então foi, ao invés de criar índices compostos, indexei cada coluna separadamente em um índice. Exemplo: For j = 1 to Len(aCampos) cSQL:= "ALTER TABLE "+tabela+" ADD INDEX K"+AllTrim(aCampos[j,2])+" ("+AllTrim(aCampos[j,2])+")" XSQLExecute(cSQL) Next id=code>id=code>Já que o MySQL "escolhe" o melhor método de se obter os dados a partir de um comando qualquer que retorne dados, desse modo, melhorou em muito a eficiência de minhas pesquisas. Porém, se o volume de dados e nº de colunas forem grandes, a 1ª indexação pode demorar um pouco, mas depois de feita, se você rodar o mesmo comando de novo, o próprio banco trata isso e apenas atualiza os indices.

Lembrando que se no lugar de você somente exportar seus dados para outra Tabela/BD, você criar o arquivo de texto, você pode usá-lo em seus sistema para criar as estruturas e adicionar todos os dados da tabela... eu acho bem mais prático!

Zeca, boa tarde...! Bom, quando eu precisava fazer isso com os meus dados, eu usava o próprio Client, que no meu caso é o MySQL-Front 2.5 Nele tem uma opção no menu chamada Im-/Export > Export tables Nesta opção, ele permite selecionar as tabelas do banco atual e exportar Dados e/ou Estrutura para um arquivo de texto (Script), para outro Banco de dados ou para outro Host...

A rotina que eu citei, seria mais ou menos assim: cHEX:= PadL(DecToHex(nCor),6,"0") ? cHEX // Código Hexadecimal de comprimento 6 já Normalizado // Códigos de cada tom de cor em Hexadecimal cHAzul:= LEFT(cHEX,2) cHVerde:= SUBSTR(cHEX,3,2) cHVermelho:= RIGHT(cHEX,2) // Conversão para Decimal, obtendo os valores originais nAzul:= HexToDec(cHAzul) nVerde:= HexToDec(cHVerde) nVermelho:= HexToDec(cHVermelho) ? cHAzul, nAzul ? cHVerde, nVerde ? cHVermelho, nVermelho id=code>id=code>

Eu não disse ? citação:me parece que pode ser problema com os dados id=quote>id=quote>Bom, o valor do campo estava NULL e não 0. Não ia achar nunca! Mas o comando estava certo! Essa função COALESCE nunca tinha usado, mas parece ser bem prática... COALESCE (Transact-SQL) Returns the first nonnull expression among its arguments.

Tem outro jeito também, mas ficaria MUITO mais complexo, então fica a título de curiosidade. Por exemplo: Para a cor vermelha, o retorno seria 255 ou FF em Hexa. Se você adotar um código HEXA de "comprimento" 6, teríamos: 0000FF para o RED 00FF00 para o GREEN FF0000 para o BLUE Como o intervalo em hexa de 0 a FF é o mesmo de 0 a 255 em Decimal, você pegaria o número retornado pela funcão ChooseColor(); Converteria para Hexadecimal e então pegaria 2 digitos para cada tom de cor, sendo: ## ## ## BL GR RE Converteria cada código hexa de 2 digitos para Decimal novamente e conseguiria um número de 0 a 255 para cada tom de cor! Complicado, mas funcional... Acho que a função nRGB() deve fazer isso internamente, só que o caminho contrário...

Bem lembrado! Se o campo estiver NULL, coloque: id=code>id=code>

Então Marcio, eu criei uma tabela aqui para teste com esses campos e inclui dois registros um com valor_pago = 0 e outro com valor_pago = 15 ambos com o mesmo cod_cliente. Executei o comando que você colocou como não funciona e retornou o registro com valor 0 enquanto o outro comando retornou os 2 registros. Portanto, este código está correto, não vi nada de errado, me parece que pode ser problema com os dados... não sei ao certo... mas espero ter ajudado e ainda ajudar com qualquer outra dúvida. obs.: Testei esses comandos somente unsando o MySQL-Front

Uma boa dica quando for executar comandos em SQL, o que eu faço aqui é o seguinte. Se o comando não está dando certo ou não está retornando o esperado, antes de executá-lo, faça por exemplo: MSGGET('','',cQuery) // acho que é isso Copie o comando e tente executá-lo usando algum Client da vida (Eu uso o MySQL-Front). Se o comando tiver algum erro, você saberá exatamente onde ocorreu e como corrigi-lo...

Esta parte aqui: citação:Se coloco cQuery+='VALOR_PAGO = ' + ANY2SQL(0)id=quote>id=quote>No seu código, você colocou cQuery+=' AND VALOR_PAGO.... Tem esse AND no código ?

Bom, pelo que vi no seu código, você está colocando outro filtro: citação:cQuery := cQuery + ' ORDER BY VENCIMENTO' *** Se coloco cQuery+='VALOR_PAGO = ' + ANY2SQL(0) Não filtra..... id=quote>id=quote> depois de ter feito o ORDER BY.Faça o seguinte que é para funcioar: cQuery:='select * from DUPLICA where ' cQuery+='COD_CLIENTE = ' + ANY2SQL( T_CODI_CLIENTE ) cQuery+=' AND VENCIMENTO <= ' + DTOS(T_PERIODO_INCIAL) cQuery+=' AND VALOR_PAGO = ' + ANY2SQL(0) cQuery:= cQuery + ' ORDER BY VENCIMENTO' id=code>id=code>É só deixar ORDER BY por último que é para funcioar. Faça este teste e retorne se funcionou ou não...