Aplicação consulta receber dataset de aplicação controle

Pessoal bom dia.

Estou com uma questão a dias para resolver e ainda não consegui fazer. Eu tenho uma aplicação controle onde eu preciso fazer diversos selects bem complexos para depois o resultado ser exibido em um grid de uma aplicação consulta. Não sei se é esta a forma correta para ser feita, mas, eu montei na aplicação controle os selects de acordo com o que o usuario informa, rodei o select com a macro sc_lookup no onvalidade da controle, e agora, o dataset gerado pelo sc_lookup desejo passar para a aplicação grid apresentar. Como eu faço a aplicação consulta receber este dataset? Agradeço muito a ajuda já que estou nisto a dias.

1 Curtida

se entendi, vc pode colocar em uma variavel-global e a mesma chamar no seu grid-consulta.

crie uma tabela para receber os dados gerados pela app de controle, após alimentar essa tabela redirecione para grid (que foi construiída com SQL dessa tabela).

Vale lembrar que deve prever questões multi-usuário e limpar sempre os dados gerados antes de realimentar para a sessão do usuário atual.

Bom dia Roberto.
Muito obrigado pela resposta. O dataset já está em uma var global, o que eu preciso fazer é passar para o grid da consulta. Qual comando/macro usar?

Bom dia Haroldo.
Muito obrigado pela atenção e sua resposta. Esqueci de dizer que estou usando a versão 9 do SC. Entendi o seu raciocínio, mas, será que não vai ficar lento? O dataset que retorno pode ter mais de 10.000 registros. Se eu após o sc_lookup fizer a gravação e depois carregar tudo novamente no grid acho que a apresentação ficaria lenta. Não haveria um jeito de passar o “dataset” direto?

ok!

eu faco da seguinte maneira:

sc_lookup(ds,"select valor from tabela where id=1");
if( !empty({ds}) ) {
   [dataset] = {ds}[0][0];
}

no grid-consulta:

vc vai receber [dataset], vc pode coloca-la no seu SQL, ou em qualquer outro lugar.

Roberto, te agradeço muito a intenção de ajuda, e desculpe-me a falta de conhecimento, mas, sou novo no SC. O dataset já está como global como falei, o que eu preciso saber, e não sei como, é justamente o que vc colocou para eu fazer na grid-consulta. Você poderia me dar um exemplo de como faço para receber este dataset na consulta?

no seu controle

sc_lookup(ds,"SELECT emissao FROM tabela");
if( !empty({ds}) ) {
    [dataset] = {ds}[0][0]
}

no seu grid-consulta
Ex: no seu SQL no grid

SELECT id,emissao,valor FROM tabela2 WHERE emissao = **[dataset]**

ou entao dentro do seu onRecord, vc tbm pode usar variavel

onRecord

sc_lookup(rs,"SELECT SUM(valor) FROM tabela1 WHERE emissao =**[dataset]**");
if( !empty({rs})) {
    $total = {rs}[0][0];
}

como vc esta recebendo o [dataset] de outra app, vc pode usa-la em qualquer lugar.

Fique com raiva da minha ignorancia não por favor…rs
Acho que ainda não consegui me fazer entender de forma correta. Na minha aplicação controle, eu tenho o trecho de código abaixo:

sc_lookup(dados_pesquisa, $sql); // onde $sql é o select complexo que fiz

if ({dados_pesquisa} === false) {
sc_alert("Erro na pesquisa => " .{dados_pesquisa_erro}, $params);
}
else {
[dsresultado] = {dados_pesquisa}; // dsresultado é a var global com o resultado do dataset.
};

Em [dsresultado] já estão todos os registros que preciso para apresentar na grid, então, eu queria saber como fazer para passar já tudo pronto para a grid, sem ter que rodar novo select pois já foi feito na controle. Acho que agora expliquei melhor

Fazer uma analise com 10mil registros acredito que seja algo pouco viável.

Você pode criar em uma única view todos esses lookups q1ue faz na controle?

Acho que o colega @BetoPessanha se equivocou, dataset não é uma variável global e sim os registros retornados dos lookups realizados na app controle.

Haroldo, a questão dos 10 mil é se o usuário fizer uma pesquisa global sem preencher dados para filtro. É difícil, sim, mas poderia acontecer. Quanto a gerar 1 view com todos os lookups creio que não dê devido eu ter que fazer vários selects diferentes, com joins complexos, e por isso a aplicação filtro não consegue fazer. O negócio é complicado mesmo. Então parti para a aplicação controle, e já consegui gerar os dados pelo sc_lookup, agora, eu gostaria, se fosse possível, passar este resultado, que é o dataset direto para a grid para não ficar lento. Já olhei tudo o que poderia fazer em termos de macros e de possibilidades, mas, estou parado nesta questão de passar os dados para a grid. Se não tiver como, tudo bem, vou fazer do jeito que for possível. E mais uma vez te agradeço pela atenção.

concordo plenamente!
a minha intensao era mostra de uma maneira simples como faria a transferencia do controle para o grid-consulta.
Consertesa existem outros metodos muito mais elaborados, que inclusive nao conheco…kkkk

O Haroldo tem razao vc pode montar uma view rodando o vc precisa sem ter q usar o controle.

Seu caso é complexo.
Eu em minhas grids, dependendo do relatório não deixo o usuário a vontade para trazer todos os registros… Se o usuário não selecionar nada no filtro eu forço um filtro padrão, por exemplo os dados do mês corrente.

Se não consegue montar uma view com essas queries, mesmo contruindo diversos Joins, pode ser que a modelagem não esteja bem montada para atender a essa necessidade, sendo assim:

Criar a tabela que sugeri inicialmente.
Criar evento no banco de dados para alimentar essa tabela na madrugada com todos os registros (como se fosse a consulta sem filtros).
Criar a grid com os filtros em cima da tabela gerada pelo job (stored procedure acionado por evento em horário de baixo uso do sistema).

Outra sugestão é gerara o relatório em PDF.

Para Selects complexos eu uso VIEW.
E chamo essa VIEW na consulta.

Boa tarde Pessoal.

Desculpem-me a demora para responder, sobre o assunto de ontem, mas, é que tive diversos contratempos hoje. Ontem, já tarde da noite, com a ajuda de uma pessoa sensacional que tive o grato prazer de conhecer, que é o Haroldo, resolvi o meu problema. O problema era complexo mesmo como ele já havia dito antes, mas, ele resolveu. Vou postar aqui a solução para quem possa ter o mesmo problema algum dia poder resolver também:

  1. Ignorei a controle que estava fazendo, e voltei para a aplicação filtro/consulta. Nesta aplicação, os campos que são de pesquisa na minha tabela principal continuaram lá no filtro, e criei outros (campos virtuais) para que eu pudesse fazer pesquisa nas outras tabelas que estão como foreign key da principal, e por ser pesquisa dinâmica, não dá para fazer com views.
  2. Após os campos criados, fiz o tratamento destes campos dentro do onscriptinit da consulta, e não no onvalidade do filtro. “Isto faz toda a diferença!”
  3. No onscriptinit, tratei o preenchimento dos campos virtuais para poder alterar o select de acordo com a minha necessidade. Abaixo posto um trecho basico do código para ajudar a compreensão:

$whereFlag = FALSE;
$whereNome = ‘’;

// utilizei em {nome} um campo texto auto-complete para pegar o codigo do nome e adicionar este código, que é a minha chave, ao filtro.
if ({nome}) {
$whereNome = " AND codigo = {nome} ";
$whereFlag = TRUE;
}

if (empty({sc_where_atual}) && $whereFlag) {
sc_select_where(add) = “where 1=1 $whereNome”;
}
else {
sc_select_where(add) = “$whereNome”;
}

Pronto, isto resolveu os meus problemas. Agora tenho que desenvolver o restante dos controles e demais campos de pesquisa. PROBLEMA RESOLVIDO!
Aqui faço um agradecimento a todos que se preocuparam em contribuir com seu conhecimento, e ao Haroldo que se preocupou em não só ajudar mas a compreender um problema que se arrastava a 1 mês sem solução. Grande abraço a todos.

1 Curtida

Ah, e não esquecer de que a tabela gerada na consulta deve ser uma tabela de tipo “temporária” no banco de dados, que a cada consulta pode ser gerada com nomes diferentes, evitando assim o conflito em ambiente multiusuário. E também resolve a questão do tamanho da tabela, pois ela ficará bem pequena com o resultado somente da consulta especificada nos parâmetros do seu formulario de controle.

“pode ser que a modelagem não esteja bem montada para atender a essa necessidade, sendo assim …”: concordo plenamente. A complexidade se torna simples quando há uma boa modelagem, uma boa normalização.
Em tempo, o que o nosso colega está querendo é um comportamento “OOP” como se estivesse utilizando um ORM para extração de dados, permitindo assim a comunicação de objetos entre as aplicações. Mas não é esse o caso do SC que utiliza metodologia não muito usual hoje em dia.