PC Toledo

Bom dia a todos.

Quintas, vc citou o SQL Server. É o da Microsoft, né?

Dá pra usar no Harbour numa boa? Um amigo meu usa e recomenda, pq com ele deu tudo certo quando teve que deixar os DBFs.

Mas ele usa Visual Fox, aqui vejo que usam muito o MySql e que tem coisa pronta pra uso no Harbour.

Pessoalmente nada contra, sempre me vi usando o MySql, mas ele falou tanto do SQL Server...

Saudações,
Mario.

Mario Mesquita escreveu:Quintas, vc citou o SQL Server. É o da Microsoft, né?
Dá pra usar no Harbour numa boa? Um amigo meu usa e recomenda, pq com ele deu tudo certo quando teve que deixar os DBFs.
Mas ele usa Visual Fox, aqui vejo que usam muito o MySql e que tem coisa pronta pra uso no Harbour.
Pessoalmente nada contra, sempre me vi usando o MySql, mas ele falou tanto do SQL Server...

Cada um tem o gosto pessoal.
Estou usando o ADO da Microsoft.
A única coisa que precisa do Harbour é: oConexao := win_OleCreateObject( "ADODB.Connection" )

o ADO e o SQLMIX trabalham com ODBC, é uma espécie de RDD/Driver para o Windows/Linux.

Tem ODBC pra: MySQL, Excel, SQL Server, MySQL, Firebird, SQLite, Access, PostgreSQL, Oracle, Visual Foxpro, ADS/NTX, ADS/CDX, planilha Open Office, e muito mais.

Para ODBC/ADO, a diferença é a string de conexão - UM TEXTO.
E lógico, particularidades dos comandos SQL.

Aqui tem exemplos de string de conexão pra diversos bancos de dados
https://www.connectionstrings.com/


Tradução disso tudo:

O Harbour usa o ODBC...
Nem sabe qual é a base de dados, se uma coisa ou outra.
Ele apenas conversa com o Windows (ou Linux) e trabalha.

Para o programador:
Ao enviar comandos SQL, vai enviar comandos que o servidor aceite.
Se tem diferenças no SQL entre cada servidor, vai ter que ajustar.
Isso é um TEXTO que enviado ao servidor, NÃO é alteração de fonte de Harbour.

Mas isso, acontece até mesmo com a mesma base.
No MySQL 8 criaram a opção de CTE, pra facilitar os comandos mais complexos
Não adianta querer usar isso no MySQL 7, ou MySQL 6, ou MySQL 5, que não vai funcionar.
Então... diferença entre SQL sempre vai existir, é algo normal.

SQLMIX trabalhar com ODBC existe faz tempo, não precisa alterar nada tão cedo.
ADO trabalhar com ODBC existe faz mais tempo ainda, não precisa alterar nada tão cedo.

Quanto a MySQL e SQL Server.....
Vamos juntar a isso também o ADS - Advantage Database Server.

O SQL Server é ótimo? sim, é ótimo.... deve custar 30.000 reais
O Advantage Database Server é ótimo? sim, é ótimo... deve custar 30.000 reais
O MySQL é ótimo? sim, é ótimo... pode ser usado por 2.000 dólares por ano, mas nunca ninguém que usa grátis foi multado
O MariaDB é ótimo? sim, é ótimo... é totalmente grátis

SQL Server também tem versão grátis, mas.... tem limitações, que podem ou não ser problema.

Qual deles é melhor?
Grátis e sem limites só tem um, nem importa saber das outras diferenças kkkkkk

NÃO é a string exatamente correta, é só pra exemplo
É só isto abaixo que precisa alteração no código fonte

oConexao:ConnectionString := "Driver={MariaDB ODBC 3.1 Driver};"
oConexao:ConnectionString := "Driver={MySQL ODBC 3.51 Driver};"
oConexao:ConnectionString := "Provider=Advantage OLE DB Provider;"
oConexao:ConnectionString := "Driver={MySQL ODBC 5.3 ANSI Driver};"
oConexao:ConnectionString := "Driver={SQLite ODBC Driver};Database=" + cFileName
oConexao:ConnectionString := [Provider=Microsoft.ACE.OLEDB.12.0;Data Source=] + cFileName // Excel

E eventuais diferenças no comando SQL.

Nota: Fonte/string apenas pra exemplo. Na hora de usar pra valer tem 2 ou 3 linhas a mais.

Bom dia a todos.

Pois é, estou acompanhando as postagens sobre a migração de DBF para SQL, e de fato empolgado com o progresso do pessoal.
Não tenho nada contra o DBF, ao contrário, trabalho muito bem com ele, agora então com o CDX, funciona muito bem, praticamente não preciso
reindexar e a velocidade é bem aceitável, até porquê minhas tabelas não são enormes, as maiores tem no máximo 300 mil registros.

A questão mesmo é se alinhar com as novidades que existem e poderão existir, poder usar outras linguagens como apoio e até mudanças no futuro
(nunca se sabe...) e nesse ponto, o DBF te prende no mundo xbase. Apesar de ser um clippeiro convicto, simpatizo com outras linguagens como Delphi e Java.
Também ando interessado em algo que possa trabalhar pela internet, caso precise acompanhar as mudanças nesses tempos de pandemia.

Acho que o que pesa a favor do MySql pra mim, é ter muitos tópicos aqui e pessoas que usam bem e já tem boa noção desse SGDB, além do Harbour ter alguma
coisa já meio pronta para essa BD. O Server pode ser muito bom, mas pouco vejo falarem dele aqui e aquele meu amigo não tem disponibilidade de me
ajudar com ele o tempo que vou precisar para ter um domínio mínimo para migrar e abandonar o DBF.

Também vi seus posts sobre o MariaDB e penso que se é pra começar do zero, que seja com ele, já que é idêntico ao MySql mas 100% free.
Isso pesa em clientes, pois você pode garantir que eles não terão despesas adicionais com licenças e podem trabalhar regularmente sem achar que tem
uma ferramenta "pirata" na sua firma. Para empresas pequenas, custos baixos são questão de sobrevivência, te ajuda e oferecer um serviço mais em conta.

Eu já li o seu tutorial de ADO e devo reler para entender os detalhes e trabalhar com Sql. O que me atrasa é tempo, mas vou ter que dar jeito nisso
senão vou ser o último a usar DBFs.

Não sei nada dobre o SQLMix mas vou dar uma olhada nas amostras do Harbour. Se ajudar a entender mais rápido, por quê não?

Saudações,
Mario.

Pra efeito didático, ou talvez até pra usar mais, existe a opção de DBF.
O mais compatível acredito que seja ADS Local, compatível com SIXCDX.
Eu usava no VB6 acessando simultâneo Clipper.

Na prática o que significa?
Você pode alterar um único módulo pra usar os mesmos DBFs do resto do aplicativo, usando comandos SQL.
Faz um módulo, achou legal, faz mais outro, e mais outro... tudo ficando em SQL, mas usando os mesmos DBFs de sempre.
E vai fazendo isso, até se sentir confortável, podendo usar o tradicional ou o SQL, durante o tempo todo.

Se sentiu confortável com SQL, aí pode continuar passando pra SQL com DBF, ou pode começar a pensar em outra base de dados.

A limitação pra ADS Local chega a ser 20 terminais, é suficiente pra muitos.
ADS Local NÃO significa monousuário, significa SEM SERVIDOR ADS, que é pago.
O ODBC é grátis, então não precisa comprar nada.

É usar SQL encima dos próprios DBFs que está acostumado a usar.
Só precisa instalar ODBC do ADS.
Não tem nada a perder, só tem vantagem de poder usar comandos SQL e ficar mais rápido que o acesso a DBF normal.
No ADS os comandos são compatíveis com SQL Server.
Mas é só lembrar que a maioria dos comandos SQL são compatíveis em qualquer servidor que aceite SQL, as diferenças vão ser em comandos mais avançados, que geralmente só vamos usar muito depois de começar a aprender.

Usar ADS local no aplicativo significa o seguinte:

Se quiser usar o Harbour normal

USE arquivo
SET INDEX TO arquivo
GOTO TOP
....
o de sempre

SE QUISER usar ADO e ADS local, NUM ÚNICO FONTE, pode

Rs := Conexao:Execute( "SELECT ..... " )

Quintas, o ADS local compartilha os índices com uma aplicação Harbour ?

Vlademiro escreveu:Quintas, o ADS local compartilha os índices com uma aplicação Harbour ?

É exatamente o que estou dizendo.
Inclusive pode misturar dentro do mesmo aplicativo, coisa que no Clipper não dava pra fazer.

A única restrição é chave compatível, senão o ADS despreza o índice diferente.

Caso não aceite StrZero(), é só substituir por Substr( Str() ) que dá no mesmo e fica compatível.

Apenas exemplo incompleto, não vai compilar.

Fui testar restaurar o backup do MySQL no SQLite.....
O MySQL tem campo INT UNSIGNED mas o SQLite não.
Já estou eliminando isso do MySQL.

Ao que parece, vai dar pra usar o mesmo backup/restore tanto no MySQL quanto no SQLite.

Só vou confirmar quando terminar de ajustar as estruturas.

Não precisa mudar. Quando a gente faz um backup entre bancos diferentes a gente só usa o script com os dados, que são os inserts. A estrutura nao entra

Realmente backup com estruturas não serve entre dos dois.

No SQLite é INTEGER e não INT.
Tirando as estruturas, o backup deve servir.
Ou uma leve conversão pelo Harbour, pra não ter que criar as estruturas manualmente.

Isso é pra usar o backup do MySQL no SQLite e vice-versa.

Pra quem nunca viu, o backup é um arquivo texto, com comandos SQL.
Os comandos pra criação de arquivos são levemente diferente entre os dois.

Estou curioso pra ver até onde vai a compatibilidade com MySQL.

Aos trancos e barrancos mas foi.
Pra quem nunca viu access e similares, é UM ÚNICO ARQUIVO que chamei de test.db, de 3.752KB

Peguei o backup do MySQL, fui fazendo os ajustes até ser aceito pelo SQLite.
Dentro tem todas as tabelas do aplicativo e índices.
Na consulta, TODAS as cidades do Brasil.
Na verdade apenas posicionei pra mostrar as informações, não foi um SELECT.
Aquele Substr( xxx, 1, 256 ) foi o HeidiSQL que colocou.

Vixe, não tem função Year()
Mas por data foi

Então, o que notei diferente entre SQLite e MySQL:

No MySQL tem campo INT, que pode ser INT(11) por exemplo
Já no SQLite é INTEGER
Isso altera a CRIAÇÃO da tabela, não o uso.

No MySQL tem os campos string: VARCHAR(), TEXT, CHAR(), etc. que seguem a codepage/collation da base
No SQLITE é obrigatório EM CADA CAMPO
Acaba nem aceitando criar índice pelos campos texto se não definir codepage/collation
Isso altera a criação da tabela, e de certa forma o uso, pra extrair informações em order alfabética, por exemplo, ou criar um índice por um campo string.

GROUP BY, MAX(), MIN(), AVG(), ORDER BY, e outros, são iguais

No MySQL existe DATE_FORMAT() pra formatar data
No SQLite se chama DATE(), com opções parecidas
No SQLite não existem as funções MONTH(), YEAR(), DAY()
Isso altera a extração de informações, tipo por mês/ano

No MySQL: GROUP BY YEAR( data ), ANO( data )
No MySQL: GROPU BY DATE_FORMAT( data, '%Y%m" )

No SQLite: GROUP BY DATE( data, '%Y%m' )
No SQLite: GROUP BY DATE( data, '%Y' ), DATE( data, '%m' )
Nota: dei uma olhada quando testei, posso ter colocado errado agora, mas é apenas pra dar uma idéia de diferença

Ou seja, dependendo do banco de dados, podem haver certas diferenças nas funções disponíveis.
De um jeito ou de outro, acaba existindo algo equivalente.

Nisso entra uma questão importante na hora de escolher a base de dados: ONDE OBTER AJUDA
A base de dados pode ser a melhor que existe no mundo, mas.... de nada adianta isso, se não tiver aonde possamos aprender alguma coisa, ou consultar exemplos.

Tava olhando, e como opções grátis temos:

SQL SERVER Express - limitado a 1GB ou 2GB
Oracle Lite - limitado a 12GB
MySQL Community - não oficialmente - sem limites
MariaDB - sem limites

Estas opções vão ter as mesmas fraquesas dos DBFs, mas existem
Elas não tem servidor, CADA APLICATIVO pode fazer alterações pela rede, igual ao DBF, então são menos seguras, apesar de funcionarem.

Access
SQLite

Também precisa levar em conta o seguinte:
Máquina 32 bits só consegue endereçar no máximo 4GB, significa arquivos com no máximo esse tamanho.
Usando cliente/servidor, e servidor 64 bits, a estação 32 bits fica limitada a esse tamanho PRA RESULTADO DE CONSULTAS

Traduzindo: lembram que falei que as consultas SQL são como um arquivo temporário? então... o limite é pra esse "arquivo temporário".
Fazer uma consulta que retorne mais de 4GB.... sei lá... acho que isso por si só já estaria errado.... seria demorado pra rede, e seria muita informação.

Nota:
Já usei MySQL, MariaDB, SQL Server Express, Access, ADS Local, e pequenos testes com SQLite.
Não tive nenhum contato com firebird, Oracle, e outros.

O PostgreSQL é muito bom tb.