SQLRDD Erro estranho

[oribeiro]

Pessoal,

Recebi um erro numa rotina com SQLRDD que com DBFCDX funciona normal.

O erro é:

   Descricao do erro.: Erro SQLRDD/1  Tentativa de gravar um registro em tabela vazia sem antes adicionar uma linha - RollBack executed.: CONTAS

Sequencia de erros
==================
   Programa: SR_WORKAREA:RUNTI Linha: 1895
   Programa: SR_WORKAREA:WRITE Linha: 2186
   Programa: SR_WORKAREA:SQLGO Linha: 3354
   Programa: SR_WORKAREA:SQLFL Linha: 4754

O trecho do programa é:

               Select(cPrg+"CONTAS")
               (cPrg+"CONTAS")->(DBSEEK( cDocto+"P"+DTOS(wDtVenc) ))
               IF (cPrg+"CONTAS")->(EOF()) .or.;
                  (cPrg+"CONTAS")->CL_FO<>cCl_Fo
                  OADbAppend()
                  REPLACE NR_CT    With GERANUMCONTA()
                  REPLACE Tipo     With "P"
                  REPLACE DtMov    With mmDate
                  REPLACE HrMov    With Time()
                  REPLACE Banco    With wBanco
                  REPLACE TpDoc    With TpDoc[2]
                  REPLACE Docum    With cDocto
                  REPLACE DtDoc    With wDtDoc
                  REPLACE Cl_Fo    With cCl_Fo
                  REPLACE Nome     With cNome
                  REPLACE DtVenc   With wDtVenc
                  REPLACE VrDocum  With wVrDocum
                  REPLACE Obs      With wObs
                  REPLACE Ca_Nr    With TCateg[2]
                  REPLACE Nr_Nf    With Right( cNF ,Len((cPrg+"CONTAS")->NR_NF))
                  DbCommit() ///// <<<<<==== O ERRO ACONTECE NESSA LINHA
                  DbUnLock()
               ELSE
                  MsgAlert("Não consegui criar a conta do vencimento "+DtoC(wDtVenc)+" porque já existe uma conta com as mesmas características.","Atenção: Verifique")
               ENDIF

O erro acontece na linha do DBCOMMIT().

Alguém já passou por essa situação com o SQLRDD?

[joaosolution]

Bom dia

Não tive este erro, mas com SQLRDD trabalho com:

oSQL   := SR_GetConnection()

oSql:Commit()
 

Att

João Bosco

[oribeiro]

Bom dia João,

Obrigado pela sua disposição em ajudar.

Eu encontrei o problema. O SQLRDD não encontra a chave se o valor passado não tiver com os brancos no final.

Exemplo com campo PROD com 15 Caracteres gravado com [1234567890     ]:

- Com DBFCDX se eu faço SEEK [1234567890] ele acha.

- Com SQLRDD se o mesmo comando não encontra o produto, então eu preciso enviar SEEK [1234567890     ] com os espaços em branco no final.

Existe algum SET de configuração que eu ajuste o SQLRDD para encontrar a chave assim como faço no DBFCDX?

[mkyx]

O correto é você usar os comandos mysql, com sqlrdd e não usar o comando xbase, com sqlrdd, já perdi dois clientes por causa disso. Os comandos vão funcionar uma hora legal, outra hora, vai dar uns paus inexplicáveis.

Sai dessa.

 

[oribeiro]

Voce está dizendo que não da para confiar no SQLRDD?

[Jorge Andrade]

 

Voce está dizendo que não da para confiar no SQLRDD?

Não Oscar, na verdade, o que ele quis dizer "Correto" é que, na concepção dele, o melhor é usar sentenças/instrução SQL puro. Claro que ela é confiável, senão, milhares de pessoas já tinha parado de usá-la. 

As vezes não dá pra vc usar SQL puro, principalmente,  quando o sistema não está bem modelado, se a base não estiver bem modelada, é perder tempo. Normalmente quem sai do DBF para SQL, se não quiser perder tempo, tem que usar os comandos xBase, até que pode modelar as bases para utilizar SQL puro de forma mais tranquila, pois o ganho é muito grande, daí,  pode até abri mão da SQLRDD.

 

[]s,

 

[mkyx]

Com o surgimento do Windows. Os dbf, que forma feito para a plataforma DOS, não combinam com a plataforma Windows, logo, o correto, é usar os comandos mysql, como: select, update, delete, insert, etc,  pode ser o puro ou via sqlrdd, eu estou migrando tudo para mysql  via sqlrdd.

 

[oribeiro]

Entendi. Muito obrigado pelos esclarecimentos. Vou estudar os comandos SQL e ir migrando aos poucos. Por ora está quase tudo funcionando com SQLRDD trabalhando com comandos DBFCDX.

[Jorge Andrade]

 

Com o surgimento do Windows. Os dbf, que forma feito para a plataforma DOS, não combinam com a plataforma Windows, logo, o correto, é usar os comandos mysql, como: select, update, delete, insert, etc,  pode ser o puro ou via sqlrdd, eu estou migrando tudo para mysql  via sqlrdd.

 

Amigo, não vou colocar pimenta no molho, mas infelizmente discordo de vc, embora devo admitir que evoluir é necessário e primordial, mas, primeiro, o DOS não morreu, e pelo jeito, salvo engano,  não vai morrer tão cedo e o windows não o matou, até agora, nas últimas versões, os sistemas nessa base estão rodando normalmente, até no linux vc consegue rodar com DBF, então condená-lo a morte sendo que ele ainda está respirando é cruel.

A evolução é necessária e faz com que a competição fique acirrada, pois os caminhos estão se estreitando e a cada dia surge uma solução de vanguarda. Quando já se rodava o DB2 em grande porte, usava-se muito DBF, BASES EM COBOL, BASES EM DATAFLEX, BTRIEVE com o  bendito FIREBIRD e outros, e iam surgindo  outras bases na micro informática pra tentar derrubar o coitado do Highlander do DBF ahauauau.

O SQL é uma solução longeva e hoje se discute os meios e as plataformas, que são cada vez mais parrudas e confiáveis. Vc tem toda razão quando incentiva outro colega a utilizar instruções sql, pois sabe-se que o tempo  ganho, além da sequência de instruções e comandos posteriores são menores.

 

[]s,

 

[kapiaba]

kkkkkkkkkkk, VAI CORITNTHIANS!! Meu DBF querido. kkkkkkkkkkkkkkkkkkkkkkkkk

[oribeiro]

Eu também sou fã do DBF, mas não tem mais como fugir desse tal do SQL.

[EDUTEK]

como eu faria um DBSEEK usando comando SQL 

 

e retornando .t. ou .f.

[mkyx]

use uso assim:

e_esta:=.F.
if select("ARQ_VETRA")=0
   e_esta:=.T.
ELSE
   SELECT ARQ_VETRA  
endif  
cSqlQ:="SELECT * FROM VETRA_CLI WHERE CODIGO="+CHR(34)+alltrim(STR(COD))+CHR(34)+";"
dbUseArea(e_esta, "SQLRDD", cSqlQ, "ARQ_VETRA")
IF ARQ_VETRA->(EOF())

    ? "FIM DE ARQUIVO, VAZIO"

ELSE

 

 

    ? "COLOQUE AQUI OS COMANDO PARA MANIPULAR OS REGISTROS ENCONTRADOS"

 

 

ENDIF

 

[EDUTEK]

beleza vou implementar no meu

[joaosolution]

Boa tarde

If Select("TMP2") > 0

   TMP2->( DbCloseArea() )

Endif

Use ("SELECT Tabela.Codigo,Tabela.Nome FROM Tabela WHERE Tabela.Codigo="+Alltrim(Str(nCodigo,10))+" ORDER BY Tabela.NOME") Alias TMP2 NEW SHARED VIA "SQLRDD"
 

If Tmp2->(LastRec())  == 0

   Return .F.

Else

    Return .T.

Endif

Att

João Bosco

 

[Pablo.Softgraf]

ORibeiro , boa noite !

Discordo totalmente do nosso amigo MKYX,  ao contrário , não perdemos clientes , ganhamos , a nossa maior solução para entrar no gerenciador de banco de dados foi o SQLRDD. acho ele fantastico, performance 100% , conjugo ele com uma página web escrita em C# e DEVEXPRESS.

Esse seu problema, está na criação do indice no gerenciador que está usando . tambem passamos por estes problemas, você deve tomar cuidado em usar variaveis para cria certos indices , realmente nem dbcommit e muito menos dbunlock funcionarão. o único que concordo é quem em certas situações deve usar comandos DML, ou seja, 

SELECT , UPDATE , DELETE... agora se fizemos uma compra de uma ferramenta que não funciona , e na época não pagamos pouco, pra que tê-la. 

Imagina se fosse ter que mudar todas as rotinas que tivemos anos de desenvolvimento em xBase, a ferramenta não se faria necessária.

Comigo funciona maravilhosamente bem. sem mais.

DBF morreu...

O meu é walking dead então.   tenho DBF´s com mais de 1milhão de registros, detalhe com .NTX, e funciona lindoooo... kkkkkk

 

 

[oribeiro]

Pablo,

Muito obrigado pelo seu comentário otimista sobre o SQLRDD. 

Estou com a minha aplicação quase que 100% funcional com ele e estou gostando, tenho apenas algumas situações estranhas como a que mencionei na mensagem inicial desse tópico, mas aos poucos estou conseguindo driblá-las. Vou seguir com essa ferramenta porque foi a única forma que encontrei para mudar sem ter que reescrever muitos códigos que estão funcionando muito bem com DBFCDX. 

Um abraço e votos de sucesso.

Oscar Ribeiro