[firebase-br] "DO SUSPEND"

[Mário Reis]

Olá boas tardes Gladiston e pessoal da lista,
Está a correr bem, sim.
A lista de campos das tabelas é gerada automaticamente pela
SIUD(Select/Insert/Update e Delete automatic procedures) do emssqlmanger
que é o que uso há muitos anos de modo que os campos não têm sido problemas
(excepto quanto a um ou outro campo calculado, mas são muito poucos).
A ideia é , como já disse, fazer a migração para a Base de Dados que estou
a migrar sem o pessoal/users terem de parar um dia sequer. A partir destes
testes parciais que ando a fazer
preparar um script que corra  a partir do* último registo *inserido na
tabela master desta base que por uma questão prática vou designar por
"Internal Data Source" e, ir procedendo à sua atualização das suas tabelas
a partir dos dados novos que existam na "External Data Source"; depois, no
final, é só mudar o caminho e os users não vão perceber que estão na base
de dados migrada, excepto num ou outro campo que muda de layout como
exemplo o NIB (C/21 dígitos) que passa a IBAN que passa a (25 dígitos) e
nem a validação do check digit internacional que mudou vão perceber. Estou
certo que vai funcionar. Obrigado pela ajuda
Abraço
Com os meus melhores cumprimentos
Mário Agostinho Reis
919262146

Esta mensagem contém informação de natureza confidencial e é
exclusivamente dirigida ao(s) destinatário(s) indicado(s). Se, por engano,
receber este email agradecemos que não o copie nem o reenvie e que nos
notifique do ocorrido através do email de resposta.


Gladiston Santana <gladiston.santana em gmail.com> escreveu no dia quinta,
28/09/2023 à(s) 12:52:

> Saudações Mario,
>
> É tranquilo o usufruto de database externo, seja para insert, update,
> delete, procedures, ...
> Eu tenho tabela de imagens de produtos, xml de notas fiscais,
> auditorias,... que não ficam no mesmo database mas são populadas e
> consultadas a todo instante.
> No caso de auditorias, eu tenho até um 'create table'  quando contextos
> novos aparecem.
> Uma recomendação nesses momentos é crie uma tabela 'footable' com o campo
> 'foocampo'  e crie um exemplo funcional menor,  que retorne o que foi
> incluido e também o statement executado, mesmo que dê erro, o statement
> executado precisa ser consultado para saber se houve problemas de
> concatenação, aspas,...ou qualquer coisa que possa provocar erro de sintaxe.
> CREATE PROCEDURE CONSULTA_EXTERNA(p_param1 varchar(30))
> RETURNS(
>   ret_campo1 varchar(30),
>   ret_psql  varchar(4096))
> begin
>   (...)
>   ret_sql='INSERT INTO TABELA(...) VALUES (....) RETURNING CAMPO_ID';
>   -- o suspend abaixo me retorna qual é o sql statement que vou executar
> antes do execute statement
>   -- se der problema, ao menos vou saber qual foi o statement que chegou
> do outro lado
>   -- quando  o psql estiver completo e na versão final, essa linha será
> comentada
>   suspend;  -- suspend de analise do ret_psql
>   FOR EXECUTE STATEMENT :ret_psql
>           ON EXTERNAL :RET_CONN_STRING
>           AS USER :RET_CONN_USER
>           PASSWORD :RET_CONN_PASSWORD
>           ROLE :RET_CONN_ROLE into :ret_campo1 DO
>   begin
>     suspend; <-- retorna para o ret_campo1 e retorna mais 1 linha
>   end
> end
>
> Depois do teste funcional estar OK, vai gradativamente aumentando os
> campos de retorno e refazendo o teste até chegar onde vc quer e quando
> chegar na versão final então comenta o suspend de analise do ret_psql.
> Os execute statement tem como maior problema saber como a string chegou do
> outro lado, se soubermos que chegou bem, o restante é cuidar que os pares
> de 'returning' que estiver no statement estejam alinhados com o into
> :campo1, :campo2 do laço for.
>
> Aqui no Brasil temos um ditado popular que diz 'o que não nos mata, apenas
> nos deixa mais forte', então seja resiliente.
> E se achar que precisa de ajuda, tem os serviços do Carlos Cantú e de
> outros colegas que podem ser contratados por 1h e resolver tal problema
> para você.
>
> []´s
>