PC Toledo

Pessoal, bom dia,

Estou engatinhando na conexão do Xharbour com o MySQL. Li alguns tópicos aqui e o caminho é seguir os samples do SQLRDD e ir testando, porem estou recebendo o erro abaixo no memo.prg

04/19/22 10:31:36: SQLExecDirect Error
42000 - 1064 - [MySQL][ODBC 8.0(a) Driver][mysqld-8.0.28]You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'Type=InnoDb' at line 9
Command sent to database :
CREATE TABLE `test_table_memo` ( `code_id` CHAR (8) NOT NULL,
`cardid` CHAR (1) ,
`d1` MEDIUMBLOB,
`d2` MEDIUMBLOB,
`d3` MEDIUMBLOB,
`d4` MEDIUMBLOB,
`sr_recno` BIGINT (15) NOT NULL UNIQUE AUTO_INCREMENT ,
`sr_deleted` CHAR (1) NOT NULL
) Type=InnoDb
Steatment handle :
Connection handle :
RetCode : -1
SR_ODBC:RUNTIMEERR Linha : 904
SR_ODBC:EXEC Linha : 394
SR_WORKAREA:SQLCREATE Linha : 5408
DBCREATE Linha : 0
MAIN Linha : 33

Conectando está, pois o fonte cria tabelas na base. O ODBC 32 bits conecta na base também.

Como podem ver, o MySQL que consegui foi o 8. Em algumas documentações no site do xHarbour é citato como compatível o MySQL 4.1. Será que não tem como usar o 8 mesmo ? Se alguém conseguiu, onde alterar essa query pois eu não encontrei em parte alguma do fonte.

Obrigado.

Não sei no MySQL 8, mas aqui uso assim:
e não Type.

Só um comentário:

No HeidiSQL, e talvez num backup do MySQL, os nomes ficam entre apóstofros (``).
Isso não é obrigatório, é mais para casos onde os nomes podem ser iguais a palavras-chave.
Por exemplo, um campo chamado SELECT, que pode confundir com o comando SELECT.

Isto é válido:

Obrigado pelas orientações e dicas, Sr José Quintas,

No entanto eu não consegui encontrar nos fontes de exemplo o local para alterar de Type para Engine. Acredito que esteja buscando de um include ou coisa do tipo, mas o fonte não me aponta qual. O comando em questão, no fonte, aparece simplesmente como:
Como posso rastrear até chegar no ponto que eu possa alterar ?

No Harbour temos todos os fontes.
No XHarbour não sei se essa RDD é comercial, e nesse caso não vai ter os fontes, e não vai ter como alterar.
Se tiver os fontes, deve ser na pasta contribs/sqlrdd

Se o seu editor de texto tiver a opção de pesquisar em vários arquivos, pode pesquisar o type=innodb em arquivos *.c, *.ch, *.prg, *.h

Faltou dizer:

Só por essa conversão...
Ainda bem que deu erro, abandone enquanto há tempo.
Vai aproveitar seus fontes, mas vai perder sua alma.

Olá!

SQLRDD é pago, comercializado pela xHarbour.com US$ 595,00...

Se tua aplicação roda apenas em Windows, pode usar ADO e não ficar preso a esta lib. Se roda em Linux ou Unix, pode usar SQLMix. Neste caso o resultado vem em formato de tabelas .DBF, o que pode não interessar. No Harbour, existem a libs hbodbc e hbmysql. Não sei se elas existem no xHarbour.

Tenho usado o SQLRDD com xHarbour há muito tempo, porém notei que em versões do MySQL superiores a 5 podem acontecer alguns problemas.
Sendo assim usávamos somente a versão 5.1.7x e mais recentemente o MariaDB 5.2

Olá!

o que pode não interessar

O SQLRDD faz a mesma coisa é um pouco pior/melhor depende do ponto de vista de cada um, para mim é pior, melhor usa ADO a classe do José Quintas, ou SQLMIX, SQLMIX o resultado é em DBF ou não, depende do grau que o programador tem para interferir na classe SQLMIX.
Pois já tem um projeto bem grande do "Gringo" Harbour _ORM e Harbour_VFP que usa SQLMIX como ponte mas altera/melhora nem sei direito li rápido os fontes e tem coisa pra "dedeu..." Até HTML tem conversão de tabelas...
The ORM acronym stands for Object Relational Mapper.
ORMs are a method to access and manipulate data using objects, instead of direct access to SQL backends or other data stores.

SQLRDD é DBF usando(simulando) SQL, continua tudo DBF(comandos), mas pode mudar tudo para SQL, neste caso o melhor é usar SQLMIX ou ADO mesmo.
Por isso não temos acesso a sintaxe SQL, escrevemos APPEND que é traduzido para INSERT e assim por diante.
Se é para escrever em SQL o SQLRDD perde seu uso. O que não ocorre com SQLMIX, nem com o ADO.
No caso ele escreveu:
dbCreate( "TEST_TABLE_MEMO", aStruct, cRDD )
Foi traduzido para isso: 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.

Saudações,
Itamar M. Lins Jr.

SQLRDD é DBF usando(simulando) SQL, continua tudo DBF(comandos), mas pode mudar tudo para SQL, neste caso o melhor é usar SQLMIX ou ADO mesmo.

O SQLRDD fez todo sentido pra mim e provavelmente para outros pois permite ir migrando aos poucos.
Quem tem pouco ou nenhum conhecimento com o mundo SQL, encontra nesta ferramenta a solução, pois pode ir usando a sintaxe DBF ao mesmo tempo em que vai aprendendo e evoluindo no conceito SQL.
Depois desta parte entendida e vencida, avalia-se a possibilidade de usar outras soluções como já apontadas. Eu optei por manter SQLRDD até porque não iria mais dar continuidade em sistemas com xHarbour, o que nos leva a outro ponto:

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.

É possível sim vários sistemas (até usando outras linguagens) usarem o mesmo banco, tabelas, etc ... pois é exatamente como tenho feito há muito tempo.

Olá!

usarem o mesmo banco, tabelas, etc ...

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 ?

pois pode ir usando a sintaxe DBF ao mesmo tempo em que vai aprendendo e evoluindo no conceito SQL.

ADO E SQLMIX fazem a mesma coisa se quiser também.

DBF não é o problema, os problemas são exatamente os comandos SQL que não podemos usar. Porque se for usar não precisa do SQLRDD.
O bom são os comandos SQL, e não usar sintaxe DBF.

Saudações,
Itamar M. Lins Jr.

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 ?

E quem nesse planeta abre o SEU banco de dados pra "programa de fora" escrever nele? O maximo que ocorre eh a disponibilizacao de API's, que assim quem continua fazendo os processos de write (escrita) é o PROPRIETARIO e CONHECEDOR do banco

Olá!

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

Depende do tamanho da sua área de atuação. Eu já vi diversas vezes, quando trabalhei com a TOTVS... Em empresas pequenas é raro.
Até aqui no forum já apareceu umas duas vezes alguém perguntando.
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!

Saudações,
Itamar M. Lins Jr.

Muito obrigado a todos pelas orientações.

Vou seguir o caminho do ADO, ao menos por enquanto, pois estamos avaliando ainda essa migração DBF > SQL.

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 ?

Quem em sã consciência abre caminho de suas tabelas para que outros programas de fora as usem ?
Onde fica a segurança dos dados nisso ?
Pouquíssimas vezes clientes pediram isso e eu disse que NÃO !

DBF não é o problema, os problemas são exatamente os comandos SQL que não podemos usar. Porque se for usar não precisa do SQLRDD.
O bom são os comandos SQL, e não usar sintaxe DBF.

Como expliquei no post anterior, é só correr a tela e reler, tá explicadinho lá o contexto.

É notório que o nosso amiguinho baiano não simpatiza com nada do mundo xHarbour, SQLRDD e etc... o que eu posso fazer ?
Sei lá, deve ter tido alguma desilusão amorosa com alguém de lá, enfim ...

Agora ... meu mundo é este ... tudo isso tem pago as contas há quase vinte anos.