Só aproveitando:
UPDATE JPREGUSO SET RUCODIGO='3' + SUBSTR( RUCODIGO, 2, 5 ) WHERE RUARQUIVO='JPPEDI' AND SUBSTR( RUCODIGO, 1, 1 ) = '9'"
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.