Pedro,
Creio que novamente uma solução prática é criar os campos onde os subselects já tragam o resultado desejado.. e simplesmente clicar e arrastar este campo para dentro do relatório.

Se vc analisar a resposta de sua pergunta anterior, verá que o uso do Subselect para criar atributo, te dá uma flexibilidade muito grande.
Creio que este seja o melhor caminho para solucionar o seu problema.




Título

Não estou conseguindo resolver o MDO.

No Banco de Dados via comando SQL consegui encontrar o resultado com o INNER JOIN abaixo:

select pv.cod_pedidov, pv.data_entrega, pvo.data_entrega

from pedido_venda pvo

inner join pedido_venda pv

on left(pv.cod_pedidov,6)=pvo.cod_pedidov

where pv.cod_pedidov='038376/A'

Mas no MDO do pedidovenda!nome não consegui resolver, tentei usar:

<attribute 

		name="DATA_ENTREGA_ORIGINAL" 

		tablename="pedido_venda" 

		fieldname="(select pvo.data_entrega

					from pedido_venda pvo

					inner join pedido_venda pv

					on left(pv.cod_pedidov,6)=$pvo.cod_pedidov

					where pv.cod_pedidov=$pv.cod_pedidov)"	 

		caption="custo_tabela" 

		datatype="6"></attribute>

Mas aparentemente ele reclama do "left", ver imagem.

Além do comando SELECT funcionar como mencionado anteriormente, consegui montar o UPDATE em um ambiente de teste em MySQL 5.6 porém não consegui reproduzir o comando no IBExpert em minha base.

Qual seria a versão do SQL?

Alguém saberia o motivo do comando abaixo não funcionar? Qual parte está errada?

Aqui o comando pode ser visto em funcionamento: http://sqlfiddle.com/#!9/ea62068/1

CREATE TABLE pedido_venda

	(`cod_pedidov` varchar(8), `data_entrega` varchar(10))

;



INSERT INTO pedido_venda

	(`cod_pedidov`, `data_entrega`)

VALUES

	('123456', '12.03.2017'),

	('123456/A', '12.04.2017'),

	('123456/B', '12.05.2017'),

	('ABCDEF', '25.10.2018'),

	('ABCDEF/1', '25.11.2018'),

	('ABCDEF/2', '25.12.2018'),

	('ZXYABC', '01.01.2019'),

	('ZXYABC/1', '01.02.2019'),

	('ZXYABC/2', '01.03.2019')

;



UPDATE 

  pedido_venda AS t1 

INNER JOIN 

  pedido_venda AS t2 

SET

  t1.data_entrega = t2.data_entrega

WHERE 

  t2.cod_pedidov = left(t1.cod_pedidov,6)

  AND

  t1.data_entrega <> t2.data_entrega;

No banco de dados utilizei somente o trecho do UPDATE e tentei algumas variações, inclusive tentando incluir um SELECT para buscar a t2.data_entrega mas sem sucesso até então.

Uma vez resolvido o comando, o próximo passo seria deixar um Script no Agendador de Tarefas do Windows para fazer esse UPDATE a cada X minutos em todos pedidos de entrega e encomenda com data diferente da do pedido original.

Pedro, bom dia!

Vamos tentar solucionar este ítem de forma definitiva, fiquei aguardando para ver se outra pessoa ajudasse.

Conforme explicado para criar um campo utilizando um select, o mais importante é descobrir qual Script utilizar.
Antes é Importante entender seu processo:

• Um pedido de venda é cadastrado, marcado como encomenda.
• Assim que o pedido de encomenda é faturado, um pedido de entrega futura é criado.
• A ligação entre o pedido de entrega futura e o pedido original, se dá através do campo AUTO_GERADA_SAIDA que está na tabela pedido_venda.
• Então é preciso fazer um join que localiza o pedido pai, por este campo.
• Para isto basta ligar com a tabela produto_pedidov, nesta tabela existe o campo SAÍDA, que a primeira nota fiscal é emitida.

Opção 1: Criar campo no gerador utilizando extensibilidade utilizando a informação acima, criar o select acima e transformar em atributo
select min(pv2.data_entrega) from pedido_venda pv2 inner join produto_pedidov ppv on ppv.pedidov=pv2.pedidov where ppv.saida=${auto_gerada_saida}
Obs: foi necessário criar o atributo auto_gerada_saida


Opção 2: Rodar comando para mudar a data do Filho com base na data de entrega do pedido pai.
update pedido_venda pv set pv.data_entrega = (select min(pv2.data_entrega) from pedido_venda pv2 inner join produto_pedidov ppv on ppv.pedidov=pv2.pedidov where ppv.saida=$.auto_gerada_saida) where pv.cod_pedidov='040892/A'

• Sugiro não usar a opção 2
• Em anexo está o MDO extendido
• Em anexo está o relatório de teste, onde testei na sua base de dados.


Importante: este não é o procedimento padrão, normalmente um consultor deve visitar a empresa para realizar este atendimento mais técnico, mas vamos abrir esta exceção.

Se sua pergunta foi respondida, clique em curtir e marcar que sua pergunta foi respondida..

Olá Edson, muito obrigado pela resposta, o campo no gerador de relatórios pelo que entendi e vi no seu teste (que testei também aqui no meu servidor) já supriria e resolveria metade dos nossos problemas.

Porém me preocupa a outra metade, pois a data dos pedidos de entrega futura continuam incorretas em relação ao pedido pai, por isso a importância do UPDATE. Imagino que essa data será importante por exemplo para que a produção desses pedidos tenham datas inferiores a data de entrega do pedido pai (e não a da errada do filho). Fora a questão de consulta em tela.

Tentei rodar o comando que me passou no IBExpert no servidor de homologação mas retornou um erro (imagem anexa) provavelmente na parte where ppv.saida=$.auto_gerada_saida)

Gostaria de ter esse script temporário corrigindo a data dos pedidos incluindo uma condição para fazer update somente dos que estiverem com datas divergentes (where pv.data_entrega <> pv2.data_entrega) até chegarmos a uma solução definitiva.

Sobre resolver isso com o consultor, já solicitei várias vezes uma solução durante as visitas e por e-mail para isso através de relatório, script e/ou banco mas nunca tive retorno, e agora começo a entender que é possível resolver (mesmo que paliativo). E mesmo que fosse esperar para resolver com consultor isso seria somente no mês que vem (data mais próxima que conseguiram me agendar...)