xHarbour x SQLRDD - Samples

[Itamar M. Lins Jr.]

Olá!

Pouquíssimas vezes clientes pediram isso e eu disse que NÃO !

Pois é! Isso no seu raio de ação... aconteceu pouquíssimas vezes... É a mesma coisa que monitor quando dá defeito. Raramente! Mas vai numa loja que conserta monitores.
Como sempre atacando as pessoas... Mas o fato é que SQLRDD é coisa velha defasada xHarbour acabou já tem no mínimos 9 anos que já era xHb...
Isso é fato, ADO/SQLMIX faz o que o SQLRDD faz e melhor.

É fato que nos últimos 10 anos de vida do Xhb só fez copiar coisas do Harbour, mais nada. Isso não tem nada a ver com desafeto é constatação mesmo.
Mas o tempo não para e continua... Vamos ver mais daqui a alguns anos...

SQLRDD, só serve para encher o peito e dizer que migrou para MySql/MariaDb etc... Mas quando pedimos para ver o código, mostra REPLACE, APPEND etc...
E como demonstrado aqui neste post só até a versão 5x pq nas novas versões nem funciona mais... Já tinha dito isso lá atrás, que iria engessar o sistema de muita gente nesse SIMULADOR de DBFs.

Saudações,
Itamar M. Lins Jr.

[janio]

Os dados pertencem a empresa e não ao dono do programa. Pode criptografar a vontade, mas se o dono da empresa acionar a justiça, qualquer empresa de software perde. Não pode criptografar/senha para não deixar acessar os dados.
Como eu disse ANTES para leitura é blz!

Caramba, e o que isso tem a ver? Que o cliente eh o proprietario do banco, ate o meus vovós sabem.
A questao levando por vc eh: "como OUTRO programa vai escrever na tabela se nao conhece os campos".

primeiro, que NINGUEM abre o SEU banco pra "outro" escrever, pq isso seria o FIM da consistencia dos dados.
segundo, que CASO (veja bem), caso exista uma parceria com programas de terceiros no mesmo cliente, VOCÊ, criador do banco, conhecedor de todos os campos, vai dizer para o terceiro: "fulano, vc vai escrever na tabela tal, e nos campos tal e tal e tal".

Caraca, isso é tao basico que eu pensava que nem precisava desenhar.

[carlaoonline]

Bom dia!


Desculpem minha intromissão e ignorância (falta de experiência) mas reparei as postagens:

E quem nesse planeta abre o SEU banco de dados pra "programa de fora" escrever nele?

e

Quem em sã consciência abre caminho de suas tabelas para que outros programas de fora as usem ?

Tenho um sistema em Harbour com LetoDb (pretendo migrar para SQL em breve) onde o Servidor fica na casa do dono da empresa. Os usuários acessam o banco de dados de outra cidade (na sede da empresa dele) , tem também mais pessoas de outra empresa em outro estado que também possuem acesso. Todos acessam e alteram o mesmo banco de dados (claro, com as devidas permissões conforme usuários e senhas).



Não vejo como poderia ser diferente, mesmo com banco de dados padrão SQL, uma vez que a programação é justamente para
isso: encurtar distância e conectar pessoas.

Há algum problema nisso ?

[Itamar M. Lins Jr.]

Olá!
Sobre o Visual xHarbour...

Última atualização: 6 de dez de 2017
What(WillBe)New in VXH
METHOD Put()
Fixed GetDesktopRect() not returning the right elements.
Fixed OnInit to not to execute in design mode
Added ToolBar property NoDivider

Constatação! é fato! está acontecendo... até que eles reativem o xHarbour é uma péssima ideia ficar indicando ou continuando usar ele e seus produtos! Até o Harbour começa a entrar nessa constatação TAMBÉM!

Saudações,
Itamar M. Lins Jr.

[Itamar M. Lins Jr.]

Olá!

primeiro, que NINGUEM abre o SEU banco pra "outro" escrever, pq isso seria o FIM da consistencia dos dados.

Não cabe a vc decidir isso. Isso vai depender de muitos fatores. Como disse antes, suas informações são inerentes ao seu UNIVERSO em que trabalha. Mas não é normal em se usando SQL criarmos tabelas coom RECNO e DELETED, entre outras coisas p/ simular DBF, etc, etc... Vamos cair em um loop.

Saudações,
Itamar M. Lins Jr.

[janio]

Há algum problema nisso ?

Nao, nenhum problema. O programa eh seu. Vc tem conhecimento de todas as tabelas e campos. Nao importa se um usuario ta acessando da China, outro da Colombia, e outro do quintal da casa dele. Isso se for o SEU programa na China, o SEU programa na Colombia, e o SEU programa no quintal da casa do usuario.

Mas não foi isso que foi levantado como "problema". O "problema" eh quando programas DIFERENTES, de DESENVOLVEDORES/EMPRESAS diferentes precisam escrever/gravar nas mesmas tabelas. Nesse caso eh como falei: Se EU fiz o banco, se EU projetei o banco, se EU é que sei o que deve ser gravado, em que tabela, em que campos, e que dados gravar... e se OUTRO PROGRAMA de UM TERCEIRO precisa tbm gravar nessa mesma tabela, nesse mesmo campo, etc... EU (criador do banco) eh que tenho o DEVER de dizer para o TERCEIRO: "vc grava na tabela tal e nos campos tal".

[alxsts]

Olá!

Como tabela de apenas leitura. Quero ver um programa de fora adicionar registros, fora os indices que precisa saber.
Repare nos dois ultimos fields! Tem RECNO e DELETED para simular DBF por isso as tabelas não podem ser compartilhadas(R/W) com outros programas/sistemas.

Como sabemos, SQLRDD é uma ferramenta que faz o meio de campo entre DBF e um SGBDR. Foi muito útil, como dito anteriormente, para migração de aplicações xBase/DBF para xBase/SQL. Mesmo depois de completada a migração, muitos continuam a usá-la.

Seria um absurdo se o SQLRDD limitasse o uso do banco de dados apenas à aplicação xBase que o criou. Ah mas tem SR_RECNO e SR_DELETED... sim, tem. Serve apenas para compatibilidade. Ah... mas e os índices? Quando se emite um CREATE INDEX... o SQLRDD converte o comando para SQL e o índice é criado no SGBDR.

Como tabela de apenas leitura. Quero ver um programa de fora adicionar registros, fora os indices que precisa saber. Como é que o programa de fora sabe o que é DELETED e RECNO ? Fora rlock(), flock(), dbunlock()...
Quem sabe disso blz, e quem não sabe ?

Não tem problema algum. É simples demonstrar isto. Se usa MySQL/MariaDB, conecte ao teu banco de dados (criado com xBase/SQLRDD) com o HeidiSQL. Ou se usa PostgreSQL, conecte via PGAdmin. Outros bancos? conecte via respectiva ferramenta. Vai ver todas as tabelas lá. Poderá fazer INSERT, SELECT, UPDATE e DELETE normalmente. O único cuidado a tomar é o seguinte: Se quiser manter a compatibilidade com o SQLRDD, ao invés de DELETE deve-se fazer UPDATE <tabela> SET SR_DELETED ='*' WHERE <condição>. Se fizer DELETE e quiser fazer RECALL no SQLRDD, o registro não vai mais existir... Note que a coluna SR_RECNO é auto increment.

E quem nesse planeta abre o SEU banco de dados pra "programa de fora" escrever nele?

Isto é relativo, depende da necessidade e de quem é o tal "programa externo" Imagina que a empresa tenha uma aplicação xBase/SQLRDD/MySQL. Ela pode construir um site com PHP ou ASP .Net e escrever no mesmo banco de dados da aplicação xbase. Sem problemas...

[Itamar M. Lins Jr.]

Olá!

Não tem problema algum. É simples demonstrar isto. Se usa MySQL/MariaDB, conecte ao teu banco de dados (criado com xBase/SQLRDD) com o HeidiSQL. Ou se usa PostgreSQL, conecte via PGAdmin. Outros bancos? conecte via respectiva ferramenta. Vai ver todas as tabelas lá. Poderá fazer INSERT, SELECT, UPDATE e DELETE normalmente. O único cuidado a tomar é o seguinte: Se quiser manter a compatibilidade com o SQLRDD, ao invés de DELETE deve-se fazer UPDATE <tabela> SET SR_DELETED ='*' WHERE <condição>. Se fizer DELETE e quiser fazer RECALL no SQLRDD, o registro não vai mais existir... Note que a coluna SR_RECNO é auto increment.

Ai SIM!

Informações técnicas, é disso que precisamos!

Saudações,
Itamar M. Lins Jr.

[alaminojunior]

Como sabemos, SQLRDD é uma ferramenta que faz o meio de campo entre DBF e um SGBDR. Foi muito útil, como dito anteriormente, para migração de aplicações xBase/DBF para xBase/SQL. Mesmo depois de completada a migração, muitos continuam a usá-la.

Exatamente, mas quem consegue enfiar isso na cabeça do sabichão baiano ?
Ele fala de mundos, situações e contextos, mas na verdade só olha para o dele, como se todas as pessoas estivessem no nível de conhecimento e experiência dele.
Então o que ele faz ? Ao invés de apontar caminhos (que ele sabe existir), inclusive os segundo ele "ultrapassados" ele ataca, diminui e relativiza o que pra muitos inclusive eu continua servindo e rendendo $$$ o que pode ser o mais importante.

Ah mas tem SR_RECNO e SR_DELETED... sim, tem. Serve apenas para compatibilidade. Ah... mas e os índices?

Mais uma vez correto !

Temos aqui de um lado os programas antigos (que não dou mais manutenção) usando SQLRDD. Ao mesmo tempo temos outra dezena de programas criados com Windev acessando nativamente as mesmas tabelas sem se preocupar com sr_recno ou sr_deleted (este último não utilizo) e convivendo numa boa !

De novo, você tem programas usando DBF ? Precisar mudar para SQL ? Não entende de SQL ? Minha opção foi pelo SQLRDD que aliás sou sempre grato ao Leonardo Machado por toda a ajuda.
Agora, você tem programas usando DBF ? Precisar mudar para SQL ? Tem conhecimentos de SQL ! Ok, soluções já apresentadas aqui no fórum e também cogite a possibilidade de sair do mundo x[H]arbour para não ficar dentro de discussões tolas como essa !

[Itamar M. Lins Jr.]

Ola!

Se fizer DELETE e quiser fazer RECALL no SQLRDD, o registro não vai mais existir...

Olhem ai o BO para alguns! Sem RECALL. E o PACK ? faz como ?
Pq o RECNO() fica sempre crescente, não muda conforme o Pack. A base de dados p/ quem usa muito DELETE, PACK vai ficar enorme.

Saudações,
Itamar M. Lins Jr.

[alxsts]

Olá!

Olhem ai o BO para alguns! Sem RECALL. E o PACK ? faz como ?
Pq o RECNO() fica sempre crescente, não muda conforme o Pack. A base de dados p/ quem usa muito DELETE, PACK vai ficar enorme.

Recall:

Código: Selecionar todos

UPDATE <tabela> SET SR_DELETED = ' ' WHERE SR_DELETED = '*'

Pack:

Código: Selecionar todos

DELETE FROM <tabela> WHERE SR_DELETED = '*'

ZAP:

Código: Selecionar todos

DELETE FROM <tabela>

Quanto ao RECNO crescente, não sei. Precisaria testar se ele renumera os registros. Provavelmente sim. Mas não tenho como testar.

[Itamar M. Lins Jr.]

Olá!

ele ataca, diminui e relativiza o que pra muitos inclusive eu continua servindo e rendendo $$$ o que pode ser o mais importante.

Quem está atacando aqui a pessoa não sou eu. Quem leva p/ o lado pessoal não sou eu.
E dai, que vc tem seu sustento ou foi sustentado com as suas ferramentas ? E as outras pessoas que não vão pagar/comprar SQLRDD fazem como ?

Ao invés de apontar caminhos (que ele sabe existir)

Já disse o que penso sobre o SQLRDD/xHarbour etc... É pq vc não sabe mas cheguei a PAGAR lá 20 poucos anos atrás pelo drive a BEMATECH FI no Linux!, xHarbour no LINUX, etc... Quando não tenho opção eu PAGO se puder.

Não custa nada COMPARAR as ferramentas.

Os caminhos são esses no mundo HARBOUR, use LetoDBf, ADO, USE SQLMIX, na minha opinião(agora) FUJA do SQLRDD e do xHarbour pq não há mais suporte, pq está parado!

Digo agora pq antes não tínhamos aqui no forum uma pessoa com os conhecimentos do José Quintas, passando as informações de como fazer a migração. Quem não sabia tinha que pagar um suporte... Agora tem informações de como iniciar, migrar de DBF para os mais USADOS SGBDS do mundo.

Saudações,
Itamar M. Lins Jr.

[Itamar M. Lins Jr.]

Olá!

UPDATE <tabela> SET SR_DELETED = ' ' WHERE SR_DELETED = '*'

Tem como usar esses comandos pelo SQLRDD ?

Saudações,
Itamar M. Lins Jr.

[janio]

Tem como usar esses comandos pelo SQLRDD ?

Caramba'! Nao precisa dizer mais nada. Está emitindo opiniões sem conhecer

[Itamar M. Lins Jr.]

Olá!

Como posso rastrear até chegar no ponto que eu possa alterar ?

Caramba'! Nao precisa dizer mais nada. Está emitindo opiniões sem conhecer

Se tem como, basta informar como fazer ao rapaz que perguntou no início do tópico.

SQLRDD tenho conhecimento básico, por conta dos problemas que já li aqui e em outros foruns.

Saudações,
Itamar M. Lins Jr.