Harbour - SQLMIX x SQLRDD

[JoséQuintas]

SQLRDD - consultas em "SQL" no formato DBF, é LIB de terceiros
RDDADO - idem, tá na lib da RDDADO
ADOXB - idem, é LIB de terceiros
SQLMIX - idem, mas funciona Windows e Linux, tá na lib SQLMIX
ADO - Somente Windows e formato ADO, faz parte do Windows

Em todas, a consulta não é atualizada, teria que abrir sempre.
E Incluir, alterar, excluir é por comando SQL.

Exceto ADO, em todas o resultado da consulta é em formato dbf.
Em ADO, é igual a milhões de usuários de qualquer linguagem, o formato é ADO.
Abrir sempre é normal, porque cada consulta tem seu próprio resultado.

No SQL é o servidor que faz o serviço.
Quando inclui no terminal, ele avisa o servidor e é o servidor que inclui.
Commit? Se é o servidor que inclui, não existe commit no terminal.
Se as consultas são diretas no servidor, o resultado é sempre atualizado.
Se vai acrescentar um campo no arquivo, é o servidor que acrescenta, e pode decidir se congela as próximas consultas que necessitem dessa nova informação
O terminal não mexe em nenhum arquivo, o servidor faz o que quiser.
Até se quiser criar índice, pode criar em uso, o servidor sabe exatamente o que está fazendo.

Acredito que com as RDDs seja igual, não sei se bloqueiam igual DBF.

Só uso ADO, sem nenhuma RDD. O resto, é pelo que andei lendo por aqui.

ADO = Microsoft, todo Windows tem, só precisa do CreateObject() do Harbour.

Um post meu antigo, com exemplo simples de ADO com DBFs

https://pctoledo.org/forum/viewto ... hilit=+ado

Independente de qualquer outra coisa, funciona no Windows muito bem, só perguntar pra qualquer um dos milhões de usuários.
A parte de programação, querendo ou não as outras opções também precisam de mudanças no fonte.
No ADO é esquecer estilo DBF de vez.

O ADO é uma espécie de RDD, a diferença das outras é que não está no Harbour, mas sim no Windows, sendo usada ou Não.
E tem controle total, sem depender de atualizações, correções ou melhorias.

E de extra, se um dia decidir abandonar o xbase, vai poder continuar usando exatamente do mesmo jeito. (será por isso que não é divulgado?)

E isso é só o arroz com feijão de um servidor, por exemplo, MySql.
Pode chegar ao ponto de eliminar até validações de campos no aplicativo, e deixar por conta do MySql.
No MySql Server, até telas de aplicativos podem estar salvas no banco de dados.

[janio]

Entendi muita coisa!

Falta apenas a criação dos 'índices compostos' em SQL!

Janio

[JoséQuintas]

O que chama de índices compostos? Mais de um campo?
Os campos são separados por vírgula, nada de somar.

[janio]

Como seria a criação em SQL do índice

Index ON Str(Codigo) + Dtos(DatEmi)

Janio

[JoséQuintas]

Usando o programa de gerenciamento HeidSql:
Clica no arquivo, clica em criar índice, preenche nome e preenche chave com codigo,datemi

ou... usando um comando SQL.
Se fizer pelo HeidiSql, ele sempre mostra qual o equivalente se fosse por comando.
Digamos que o HeidiSql é o DBASE do SQL, uma das opções disponíveis.

Mas se for apenas pra receber a consulta em ordem, não precisa disso.
Já pede pro servidor entregar tudo pronto pro terminal, já na ordem que quiser.

Faltou falar de um grande diferencial:
No terminal não existe nenhum arquivo aberto, apenas a conexão.

Traduzindo mais ainda cliente/servidor, chamado popularmente de "SQL":

No terminal não existem arquivos.

Vamos supor que o temporário fosse TXT.
Voce passa o comando pro servidor, e o servidor te retorna um TXT com o resultado.
No caso das RDDs, o retorno é convertido pra formato DBF.
No caso do ADO, o retorno é convertido pra formato ADO.

[JoséQuintas]

Mais um exemplo... relatório de clientes em ordem alfabética:

Código: Selecionar todos

oRetorno := cnMySql:Execute( "SELECT * FROM CLIENTES ORDER BY NOME" )

Se tiver milhões de registros no servidor, e essa consulta estiver demorada, vai lá no servidor e cria um índice por nome.
Não precisa mexer nada no programa.
O índice não precisa existir, mas se existir vai ser usado pelo servidor pra deixar a consulta mais rápida.

Mesma coisa se for por UF + Cidade + nome

Código: Selecionar todos

oRetorno := cnMySqlExecute( "SELECT * FROM CLIENTES ORDER BY UF, CIDADE, NOME" )

Nota: o comando SQL é o mesmo em todos, mas este exemplo seria usando ADO.

Lógico, se vai emitir relatório só com nome, endereco, cidade e UF, vai ser muito mais rápido se pedir pro servidor somente esses campos:

Código: Selecionar todos

oRetorno := cnMySqlExecute( "SELECT NOME, ENDERECO, CIDADE, UF FROM CLIENTES ORDER BY UF, CIDADE, NOME" )

[Itamar M. Lins Jr.]

Em todas, a consulta não é atualizada, teria que abrir sempre.
E Incluir, alterar, excluir é por comando SQL.

Com RDDSQL é possivel fazer "REPLACE X WITH Y" ou DbAppend(), o recno() funciona! no RDDSQL, porque ele cria dois campos a mais lá na tabela os tais:

Código: Selecionar todos

   [SR_RECNO] NUMERIC (15,0) IDENTITY,
   [SR_DELETED] CHAR (1)  NOT NULL

E começa a tratar tudo com se fosse DBF, o pessoal quer é se livrar de DBF, dessa tecnica, enquanto outros vem trazendo tudo isso p/ bancos relacionais gerando os mesmos problemas que existem na forma DBF de trabalhar.
O drive magicamente joga isso na tabela! Agora em ambiente multi usuário como fica isso ? delete(),flock(),rlock(),pack()... é isso que o povo do SQL pira... já que não precisa mais nada disso.
Imaginem dbgobottom() e depois o dbskip(), para posicionar o cursor no registro fantasma no MySQL criar registro fantasma na TABELA SQL ? e outras particularidades do DBF, que o pessoal do SGBD´s nem pensam nisso... isso p/ eles é doidice registro fantasma no MYSQL ?

Por isso as pessoas que já tem costume com SQL acha que é aberração, já outros adoram.

Saudações.
Itamar M. Lins Jr.

[janio]

Ok,

Eu uso Mediator (similar ao SQLRDD), onde tbm eh possivel usar diretamente comandos SQL (Select * from ...). Nesse caso, no Mediator, eh criado uma tabela temporária la no servidor em que podemos manipulá-la como se dbf fosse. Agora estou vendo que mesmo um dbskip() nessa tabela temporia... eh feito um select no servidor!

O que por um momento mim passou pela cabeça foi que usando mediator fazendo as consultas em SQL, seu uso ficaria idêntico ao SQLMIX. Ocorre que não! Mesmo fazendo consultas em SQL no mediator, seu uso não se compara ao SQLMIX pq no momento em que fazemos um dbskip(), dbgotop() no resultado dessa consulta (feita em SQL), la no servidor ta sendo feito um Select * From para cada dbskip() ou comando xbase.

Outra coisa, há limite de criação de indices?

Janio

[JoséQuintas]

Um exemplo de uso do rlock() seria pra atualizar estoque.
Como atualizar no MySql sem bloquear registro?
Não precisa, é o servidor que faz, então o servidor já vai atender um usuário de cada vez (e não pense que isso causa problemas pra milhares de usuários).

Código: Selecionar todos

cnMySql:Execute( "UPDATE ARQUIVOESTOQUE SET QUANTIDADE=QUANTIDADE+1 WHERE PRODUTO=10" )

O terminal apenas pede pro servidor atualizar, o terminal não faz conta nenhuma.

Quanto mais fora do estilo DBF, melhor.
Acho que agora entendi porque não se importaram em fazer funcionar igual dbf os comandos append, replace, delete, etc.

[Itamar M. Lins Jr.]

Como seria a criação em SQL do índice
Index ON Str(Codigo) + Dtos(DatEmi)

Isso não tem necessidade Jairo, é coisa do passado.
Vc solicita ao servidor: "Me mande os campos tais, na ordem tal" e pronto, vem o resultado, vc imprime, mostra na tela faz o que desejar, o servidor está prontinho esperando outro pedido, isso é muito rápido.

Saudações,
Itamar M. Lins Jr.

[JoséQuintas]

Não é exatamente assim, índices ainda existem.
É só olhar meu post anterior.

E limites....
Pra quem usa DBF, nem precisa se preocupar com limites.
Talvez o limite seja quantos HDs poderá colocar na máquina.
Só imaginar que o google usa o MySql pra gerenciar as pesquisas mundiais.
Qual será o tamanho da base de dados do google?

Lógico... se tiver muitos índices, os índices terão que ser atualizados e levará tempo, então não vai ficar criando índice à toa.

[janio]

Ok,

Apesar de nomes iguais, o conceito eh diferente!

Pelas explicações de vcs, eu entendi que os INDICES em SQL servem para agilar uma consulta e não para trazer o resultado naquela ordem desejada. Diferentemente dos nossos indices em DBF que tanto servem para agilar a consulta (não precisar varrer o dbf inteiro), quanto para ter a ordem desejada!

Nomes iguais, conceitos diferentes! Como saber dessas coisas?? so tendo uma aula como essa q vcs estão dando!

Janio

[JoséQuintas]

Talvez seja mais simples do que pensa.
USE.

Hoje seu terminal faz as coisas via rede.
A maioria das coisas vai ser mais rápida por fazer pelo servidor.
Assim que estiver usando, vai poder ver o que tem de recurso pra melhorar ainda mais.

[JoséQuintas]

Convém lembrar:
O DBF costuma ser usado por ser independente e não precisar instalar nada.
Com certeza com MySql, vai precisar instalar o MySql no servidor, e isso dependerá do servidor de cada empresa.
E nos terminais o "driver" de conexão, conhecido por ODBC. Do mesmo jeito que existe driver pra cada tipo de impressora, existe o driver pra cada tipo de banco de dados (MySql, SQL Server, Oracle, etc).
No Windows só vém pré-instalado o que é da Microsoft.

Quanto às RDDs mencionadas, confirme se é só isso mesmo, ou se dispensa o ODBC.

[janio]

- Com mediator precisa instalar no servidor o Mysql, o drive ODBC e o Servidor Mediator. Nas estações so o nosso executável mesmo;
- Com SQLRDD não precisa instalar nada no servidor, além do proprio mysql. Ja nas estações precisa de algumas dll's;
- SQLMIX... não sei!

Janio