PC Toledo

Olá,

Estou adaptando alguns sistemas xHarbour + DBF para trabalharem com SqlServer 2008. Estou utilizando SQLRDD para isto.

O cenário da minha dúvida é o seguinte, tenho abaixo uma tabela (chamada TIPJUST) ja criada no SqlServer 2008 com alguns registros:

CODIGO (Char 1) TIPO (Char 2) SR_RECNO (Numeric 15)
1 01 1
1 02 2
2 01 3
2 02 4
2 03 5
3 01 6
3 02 7

Esta tabela está indexada da seguinte maneira:
INDEX ON codigo TAG tj1 TO ind_tj1
INDEX ON codigo + DESCEND(tipo) TAG tj2 TO ind_tj2

Problema: Em um determinado ponto do meu programa, quando executo as linhas abaixo, após a execução do comando "SEEK", o "ponteiro" de registros se posiciona no registro correspondente ao SR_RECNO = 4, ao invés de posicionar-se no SR_RECNO = 5 (como seria no DBF).
SET ORDER TO 2
SEEK "2" SOFTSEEK

Tenho esta situação em dezenas pontos e tabelas diferentes dos meus sistemas. Alguém tem alguma idéia do que eu poderia tentar.

Só pra constar, já tentei uma porção de coisas (todas não apresentaram erro, porém, continuaram sem sucesso) entre elas:
* Versão mais atual do xBuildW (atualmente estou usando a 4.5 de 10/2007)
* Criação do índice através do próprio CREATE INDEX da linguagem SQL ao invés de utilizar o tradicional INDEX ON do xHarbour

Grato.

Olá!

Seja bem-vindo ao fórum!

Pelo menos no Clipper, quando se utiliza a função Descend() na criação de um índice, é necessário usar também na pesquisa...

Experimente usar (não testei mas acho que o caminho é este):

Olá!

Em tempo:
no Clipper 5.3, a função DBSeek() aceita um terceiro parâmetro (descend) que, quando setado para .T., especifica que a pesquisa será descendente. Não sei se colocaram isso no [x]Harbour. Verifique.

Olá Alexandre, obrigado pelas dicas.

Já havia pesquisado sobre o 3º parâmetro do DbSeek() no xHarbour e possui exatamente a mesma funcionalidade (idêntica) à no Clipper 5.3. Porém, mesmo passando .T. e/ou .F., o resultado ficou inalterado. O SEEK "2" SOFTSEEK continua posicionando no mesmo registro.

Quanto ao exemplo do SEEK "2" + DESCEND("") SOFTSEEK ao invés do SEEK "2" SOFTSEEK, deixou também o resultado inalterado.

Entre uma pesquisada e outra, notei que após aplicado o SET ORDER TO 2, se visualizada a tabela através da função BROWSE() ou DBEDIT(), nota-se que a ordenação dos dados demonstrados já não obedecem aos conceitos tradicionais, isto é, não traz ordenadamente correto a exibição dos dados nas colunas CODIGO (em ascendente) e a TIPO (em descendente). Traz tudo meio que bagunçado! Exemplo:

CODIGO (Char 1) TIPO (Char 2) SR_RECNO (Numeric 15)
2 02 4
2 01 3
2 03 5

Já estou me aproximando da conclusão de usando o SQLRDD com SqlServer (e Oracle inclusive, testei também) que a função DESCEND() quando utilizada em índices de chave composta, não tem a mesma proposta que quando for utilizada no ambiente SQLRDD com DBF.

Está me parecendo que bastou estar em ambiente xHarbour + SQLRDD em um banco mais parrudo, a função DESCEND() muda completamente sua funcionalidade. Muito estranho.

Se souber de mais algo, por favor, não deixe de comentar aqui no fórum.

Grato.

Eu uso SQLRDD + PostgreSql e não tenho esse problema, qual Banco de dados SQL você está tendo esse problema ? de qual data é seu SQLRDD ? é para BCC ?

Olá Leonardo,

Estou usando SqlServer 2008. Meu SQLRDD é a versão 7.1 (de 11/2007) e sim é p/BCC.

Se souber de mais algo, por favor, não deixe de comentar.

Grato.

Acho que sua versão que deve está desatualizada, tente falar com o Luiz Culik ou com Marcelo Lombardo que vale a pena atualizar para versão mais atual do Sqlrdd, e tem também o SQLEX já vem embutido que é uma versão muito rápida e para você que usa SQL SERVER vai ser mamão com açúcar.

Olá,

Seguindo a última orientação aqui postada ref.a este problema, contactei os srs. Luiz Culik (nem sequer respondeu o e-mail) e Marcelo Lombardo (Disse que "acredita" que comprando a atualização do SQLRDD + cortesia SQLEX, solucionarei os problemas citados). Mediante tal informação, baixei a versão demo SQLRDD-SQLEX-xHarbour-Builder-DEMO-March2010-build31 e fiz dezenas de testes para tentar solucionar o problema. Resultado: Confesso que fiquei bastante assustado com a quantidade de problemas e erros ao compilar meu software com esta versão Demo!

Logo nas primeiras compilações, notei que, ao contrário da SQLRDD Full (Nov 2007) a qual eu possuo, nesta nova Demo não consta em suas respectivas bibliotecas disponíveis (pelo menos nesta versão Demo) a função SETLASTKEY() da CATools. Portanto, tive que "reescrevê-la". Daí por diante, continuando a usar o driver SQLRDD (desta vez atualizado e ainda no BD Postgres, pois, nos demais BD continuaram apresentando os mesmos problemas), me pareceu realmente um pouco mais rápido, pois, uma tarefa que gastava muitas horas, agora está levando apenas 1 hora. A diferença é realmente notável, porém, sabe como são os clientes, p/ eles ainda está lento demais (em parte até concordo, pela relevância da tarefa que é executar 15 comandos "index on" em um mesmo DBF/Tabela).

Passei então a experimentar o acesso via SQLEX com conexão via ODBC (exigência do SqlEx) e para minha surpresa, após horas e horas tentando obtive os seguintes resultados:

1) SQLSERVER 2008 --> Conecta numa boa, porém, ocorre o Erro "Sql execution error at getPreparedSeek, return code: -1" em qualquer comando Seek, DbSeek ou Append From que executo (coisa que via SQLRDD não ocorre). Alguém tem alguma idéia do motivo e/ou o que eu poderia tentar agora?

2) POSTGRES v8.2 --> Não consegui conectar nem em meu software, quanto mais no exemplo (arquivo topconn.prg) do próprio pacote do SqlRdd/SqlEx (encontrado na pasta \xHB\samples\sqlrdd). Em ambos os cenários o mesmo erro (conforme demonstrado abaixo) me foi apresentado:

(Erro apresentado durante a execução do SR_AddConnection(CONNECT_ODBC, "dsn=pgs83;uid=postgres;pwd=Maker@1;dtb=BDSQLRDD2") ou também com SR_AddConnection(CONNECT_ODBC,"dsn=pgs83")
C:\MeuSoft>meusoft.exe)

+-----------------------------------------------------------+
¦ Error SQLRDD/0 SQL execution error at SQLCONNECT, return ¦
¦ code: 0, state: , description: . Arguments: ( [ 1] = ¦
¦ Type: C Val: MySQL Driver version 5 is not compatible ¦
¦ with SQLRDD) ¦
¦ ¦
¦ Quit ¦
+-----------------------------------------------------------+

Ao dar enter no "Quit" aparece então:


Error SQLRDD/0 SQL execution error at SQLCONNECT, return code: 0, state: , desc
ription: . Arguments: ( [ 1] = Type: C Val: MySQL Driver version 5 is not compat
ible with SQLRDD)

Error at ...: SQLCONNECT(880) in Module: ..\..\source\sqlsrodbc.c
Called from : SR_ODBC:INIFIELDS(278) in Module: ..\..\source\sqlodbc.prg
Called from : SR_ODBC:EXEC(504) in Module: ..\..\source\sqlconnection.prg
Called from : SR_SETENVSQLRDD(689) in Module: ..\..\source\sqlrdd0.prg
Called from : SR_ADDCONNECTION(458) in Module: ..\..\source\sqlrdd0.prg
Called from : CONECTARBD(144) in Module: BRHB.PRG
Called from : INIC$(513) in Module: FOLHA.PRG

Estranho não é? Estou tentando fazer conexão com o POSTGRES...porque será que o erro menciona MySQL Driver version 5??? O que tem a ver? Tentei inclusive copiar o arquivo LIBMYSQL.DLL p/a mesma pasta do meu executável, porém, foi em vão...continua dando o mesmo erro.

3) FIREBIRD v2.1 --> Até consegui fazer a conexão perfeitamente, porém, em meu software há rotinas que fazem consistência/atualização de estrutura dos arquivos DBF/Tabelas e, uso e abuso da função DbStruct(). Problema: Apenas no Firebird, o SqlEx está me trazendo no Array de retorno da função DbStruct() uma coluna que o driver cria no BD Firebird chamada "BACKUP_" do tipo "Integer" e "Null". Ao contrário do que faz com as colunas "SR_Deleted" e "SR_Recno", não está fazendo o mesmo com esta "BACKUP_". Detalhe: Isto o SqlEx está fazendo apenas no Firebird. No SQLServer fez certinho!

Alguém tem alguma idéia do que posso estar tentando agora (além é claro de talvez reescrever também a DBSTRUCT() além de já ter feito com a SETLASTKEY()) ?

Se algum companheiro tiver alguma informação ou dica a respeito e puder contribuir, agradeço imensamente.

Leonardo.

Boa noite Leonardo,

vamos la:

primeiro -> a funcao seek do sqlrdd nao funciona para chaves compostas, fica maluquinha, ora encontra ora nao encontra, como eu tambem migrei meu sistema para xharbour + sqlrdd tive que criar uma funcao manual e fazer a chamada em cada prg da seguinte forma: #include "supernet.ch"

conteudo do supernet.ch
/*Definicoes do usuario*/
#command SEEK <xpr> [<soft: SOFTSEEK>] => SuperSeek( <xpr>, if( <.soft.>, .T., NIL ) )
#xcommand SEEK <xpr> [<soft: SOFTSEEK>] => SuperSeek( <xpr>, if( <.soft.>, .T., NIL ) )


segundo tive que criar a funcao SuperSeek
utilizando o comando interno do sqlrdd "dbusearea", resumindo eu nao deixo o sqlrdd executar o seek

terceiro. este erro mencionado quando dar o seek com o sqlex erro code -1, acontece comigo tambem e nao conseguir ainda resolver.

quarto: fazendo o teste do skip no sqlrdd e sqlex para comparacao, o sqlrdd é 3 veses mais rapido ainda que o sqlex

(para testes acima foi utilizado versao do postgressql 8.3.8 e xbulid demo janeiro / 2010).
Hercules Ribeiro
hercules.ribeiro@gmail.com

Olá Hercules,
Com certeza deve ter algo de errado no seu sistema, por que se o Seek não funcionasse no SQLRDD meu sistema inteiro estaria com problemas e eu estaria com um grande problemão, por que tenho milhares de seek em meu sistema.
De uma revisada em seu sistema, comece partindo para um exemplo simples compilando apartir dos Samples que vem junto com SQLRDD