bencz escreveu:bom, isso não é para ser um problema... basta criar o índice...
Nos clientes, IDCADASTRO é numérico, e nos pedidos era caractere.
O estoque é recém chegado ao MySQL, o campo de IDPRODUTO é caractere, mas no cadastro de produtos é numérico.
Essa mistura é normal no MySQL, mas conforme a situação causa uma lentidão tremenda,
LEFT JOIN ... ON JPESTOQUE.ESPRODUTO (VARCHAR) = JPPRODUTO.IDPRODUTO (INT)
Tinha me esquecido que isso aconteceu com pedidos e clientes, e somente em algumas pesquisas.
Por isso acho que deve ser a mesma coisa, mas agora com produtos.
NÃO é problema do MySQL, ele até faz muito em relacionar 1 com "000001".
Em querys mais simples isso funciona normalmente, mas em outras pode acontecer a lentidão.
O aplicativo vinha trabalhando como caractere, pro DBF, usando StrZero(x,6) na gravação.
No MYSQL procurei usar campos incremental, então tiveram que ser numéricos.
Pra gravação dupla, mantive caractere pra outros campos "não chave".
Há algum tempo estou deixando só numérico no aplicativo, e desvinculando dessa necessidade dos meus DBFs antigos/compatíveis.
Próximo passo:
Definitivamente só usar caractere na leitura/gravação de DBF - se ainda existir o DBF.
E no MySQL, obrigatoriamente deixar numérico em TUDO, não apenas aonde é chave primária.
Nota:
Não se trata do MySQL não aceitar número ou caractere.
É de usar código de produto no cadastro como sendo numérico, e no movimento de estoque o código do produto como caractere.
Digamos que durante a migração foi possível fazer errado, mas chegou a hora de fazer certo.
Ainda vou poder usar na gravação: SET CODIGO = "000001", mesmo se o campo for numérico.
Isso basta pra continuar com a gravação dupla, até acabar com o DBF de vez.