seria normal do dbf isto:
Código: Selecionar todos
SELECT JPITPED
REPLACE ALL JPITPED->ICMS WITH JPITPED->VALOR * JPITPED->IMPOSTO FOR JPITPED->PEDIDO=10
Código: Selecionar todos
SELECT JPITPED
SET RELATION TO JPITPED->PEDIDO INTO JPPEDIDO, JPITPED->PRODUTO INTO JPPRODUTO, JPPEDIDO->CLIENTE INTO JPCLIENTE
REPLACE ALL JPITPED->ICMS WITH JPITPED->VALOR * JPITPED->IMPOSTO, JPITPED->IPI WITH JPITPED->VALOR * JPPRODUTO->IPI WHERE JPITPED.PEDIDO = 10
Código: Selecionar todos
UPDATE JPITPED
INNER JOIN JPPEDIDO ON JPPEDIDO.PEDIDO = JPITPED.PEDIDO
INNER JOIN JPPRODUTO ON JPITPED.PRODUTO = JPPRODUTO.IPPRODUTO
INNER JOIN JPCLIENTE ON JPPEDIDO.CLIENTE = JPCLIENTE.CLIENTE
SET ICMS = VALOR * IMPOSTO,
IPI = VALOR * JPPRODUTO.IPI
WHERE PEDIDO = 10
o SELECT é definido indicando a tabela
INNER JOIN é o SET RELATION
WHERE é o FOR
Da mesma forma que o DBF, o ALIAS pode ser opcional caso o nome do campo seja único JPPEDIDO->PEDIDO, JPPEDIDO.PEDIDO ou IDPEDIDO se só existir na tabela de pedido
SQL é complicado ?
Não considere coisa nova como totalmente desconhecida.
Tente encontrar alguma coisa que possa usar como referência.
Com a referência certa, tudo vira coisa velha com roupagem nova.
Com essa comparação, parece que o SQL é um dBASE melhorado.
Ou... o dBASE é um SQL mais limitado.
Coisas que precisavam de várias linhas, estão numa linha só.
E como não existe área atual, arquivo aberto, etc. precisa indicar aonde as coisas estão.
O que tem de novidade ? quase nada, pelo menos nesse comando acima.
E quanto ao funcionamento?
É o servidor quem vai fazer o trabalho pesado, não o programa, isso sim é muito diferente, ZERO de uso de rede e/ou internet. ZERO de uso do computador local, ZERO de uso de disco local, ZERO de antivírus atrapalhando acesso a disco, ZERO de problema de faltar luz no terminal, ZERO de índice corrompido, etc.
Tá usando Windows, Linux, sistema web, harbour, xharbour, outro.... e daí ? é o servidor que está fazendo o trabalho.