PC Toledo

Ainda bem que suspendi a atualização para MySQL.
Nenhum problema, mas poderia ser....
Só quem está acostumado com MySQL sabe qual é o ERRO GRAVE nesses comandos.
Nem preciso dizer que esperava o mesmo resultado do Harbour... mas não é.

A imagem diz tudo
Como eu já disse por aqui.... sou principiante em MySQL, apesar de já fazer uso dele.

Ainda bem que dei uma conferida no resultado, senão.... teria sido problema renumerar pedidos...

Só que agora fiquei na dúvida....

Se uso o comando de concatenar string, ou se uso operação aritmética para o campo string.
Seria trocar o número, mas do campo caractere, por numero - 600000
Na dúvida, usar o comando inicial, trocando por CONCAT() ao invés de +

Só aproveitando:
Isso mostra que trocar de DBF pra MySQL não se trata apenas de decidir se usa ADO, SQLMIX, etc.
Há diferenças nos comandos, e querendo ou não, é bom aprender bem o que vai usar, pra não causar erros até irrecuperáveis.

Tenho lá num cliente os pedidos que começam em 700.000, e até chegando no limite de 999.999
Então vou renumerar tudo tirando 600.000, mas o campo é caractere.
Um simples erro desse, e seriam perdidos todos os relacionamentos com número de pedido.

ia trocar o 7... por 1..., mas o comando estava errado, porque no MySQL somar se refere a número.
O Concat() no lugar da soma resolve, que é pra concatenar/juntar strings, mas pelo jeito também resolveria trocar o número por número - 600000, mesmo o campo sendo string.

Não se trata de defeito no MySQL, trata-se apenas da forma como ele interpreta os comandos.

Achei que vale a pena chamar a atenção pra isso.
Não é o aplicativo que precisa aprender MySQL, somos nós !!!

Vou alterando devagar e vou acostumando com esses detalhes.

Nota:
O campo faz vínculo do pedido em DBF com o histórico de alterações em MySQL.
Estou renumerando agora, pra não precisar mexer quando os pedidos forem pro MySQL.
Para o usuário, vai ser só considerar -600.000 para as numerações, não vai criar nenhum problema grave de adaptação.

Pois é... sempre precisa testar antes....

MAX( 0, 1 )

Isso parece... mas não é...

No MySql a função MAX() é pra retornar o maior valor de UM CAMPO, e não o maior entre dois valores.

Greatest(), e Least() são o que conhecemos como Max() e Min() do Harbour.

SELECT MAX( VALOR ), MIN( VALOR ) FROM BANCO

Isso é pra retornar o maior e menor conteúdo do campo VALOR.

Vai ser difícil acostumar com essas coisas....

Erro executando comando:-2147467259 [MySQL][ODBC 5.3(a) Driver][mysqld-5.7.12-log]Column 'LFCFOP' specified twice

Aqui é interessante....

REPLACE A WITH 1, A WITH 2

Isso em DBF tudo bem, mas em MySQL dá erro, porque o campo está indicado duas vezes.

Dá pra dizer que é um erro de fonte, mas que DBF aceita errado (ou o compilador).

Acabo de confirmar outra coisa:

Pesquisar "string" em campo numérico é rápido, mas o contrário não.

explicando:

idCadastro é numérico, então select * from jpcadastro where idCadastro='000006'
isso é rápido, porque só converte o código de pesquisa

fiPedido é caractere, então select * from jpfinan where fipedido=6
isso é lento, porque precisa converter CADA campo do financeiro

Faz muuuuita diferença no JOIN. (relacionamento).
Vou ter que rever todos os campos do MySQL, pra não ficar uma carroça quando preciso usar JOIN.

A diferença é brutal. Minutos ao invés de 1 segundo.