Senhas Duplicadas

This site is best viewed in a modern browser with JavaScript enabled.

Senhas Duplicadas

rarandrade

No hospital aonde trabalho utilizo o NovoSga 1.5.1 para gerenciar todo o atendimento ambulatorial e de raiox dos pacientes em consulta e hoje aconteceu a seguinte situação dois paciente diferente pegaram a mesma senha A126. Consultando o monitor e banco de dados a senha foi emitida por dois atendentes diferentes, queria saber se alguém do grupo já teve esse problema e sabe como resolver. Segundo o pessoal que realiza os atendimentos essa não é a primeira vez que isso acontece.

Primeira Senha Emitida:
https://imgur.com/a/hPrqO53

Segunda Senha Emitida:
https://imgur.com/a/Vj3OWTF

Tabela do Banco:
https://imgur.com/a/KvaUM3z

Servidor estou usando:

Debian 7
PHP 5.4
Postgres 9.1
Apache2

rarandrade

@rogeriolino tem alguma coisa q eu possa fazer para resolver o problema ?

Pois tenho em torno de 650 senhas emitidas todos os dias e a duplicação esta ficando mais frequente

rogeriolino

rarandrade teste a versão 2.0

rarandrade

rogeriolino Sei que vc não ganha nada com o sistema, mas acho que seria interessante pensar em uma compatibilização dos dados da versão anterior para a versão nova, pois muita gente assim com eu não tem como abandonar todo o histórico que tem na versão 1.5.1 e começar do zero na versão 2.0.

rarandrade

@rogeriolino Nao tenho como utilizar a versão 2.0 pois ainda não tem a migração dos dados da versão anterior 1.5.1 tenho todo um histórico de atendimento e tb não tenho como cadastrar todos os usuarios no sistema novamente ficaria inviável.

Mas quanto as senha achei um solução no antigo fórum caso alguém esteja com o mesmo problema e so executar essa função no banco de dados que resolve o problema pelo menos para mim resolveu.

Primeiro comando

CREATE OR REPLACE FUNCTION bloqueia_repetidos()
RETURNS trigger AS
$BODY$
DECLARE

BEGIN

if exists(select * from atendimentos where unidade_id = NEW.unidade_id and num_senha = NEW.num_senha and atendimento_id is null and NEW.atendimento_id is null) then
raise exception 'Registro duplicado, por favor repita a operação.';
else
return NEW;
end if;

END;
$BODY$
LANGUAGE plpgsql VOLATILE
COST 100;
ALTER FUNCTION bloqueia_repetidos()
OWNER TO novosga;

Segundo comando

CREATE TRIGGER bloqueia_repetidos
BEFORE INSERT
ON atendimentos
FOR EACH ROW
EXECUTE PROCEDURE bloqueia_repetidos();

Vera

@rarandrade obrigada por compartilhar a dica.

Para eliminar as duplicidades, em Nov/2017 segui a sugestão do @netdados e alterei 2 linhas do arquivo src/Novosga/Service/AtendimentoService.php para a ordenação dos dados ser Order by ID no lugar de Order by numerosenha.

Dias depois o problema tornou a ocorrer (ver registro no Fórum antigo neste link http://forum.novosga.org/discussion/comment/2568/#Comment_2568)

Pelo SQL abaixo identifiquei que entre 06/06/2017 e ontem tivemos 290 ocorrências de senhas duplicadas. Em geral acontecem nas unidades onde temos mais de um balcão de triagem. Nesta semana aconteceu 6 vezes.

Vou criar a função e a trigger no banco de dados conforme você registrou.

-- SQL para identificar as duplicidades de dias anteriores ao dia atual
-- Para analisar ocorrências do dia basta alterar para a tabela atendimentos
select date_format(a.dt_cheg,'%Y/%m/%d') ,a.unidade_id, a.num_senha,count(*)
from historico_atendimentos a
where a.atendimento_id is null -- não é senha redirecionada
group by date_format(a.dt_cheg,'%Y/%m/%d') ,a.unidade_id, a.num_senha having count(*)>1  -- 1 senha com mais de um registro 
order by date_format(a.dt_cheg,'%Y/%m/%d') ,a.unidade_id, a.num_senha

Assim como você, aqui continuamos usando a versão 1.5.1 com banco de dados MySQL pois estamos aguardando o script de conversão dos dados para iniciar os testes com a versão 2.0. Temos um histórico de 207 mil senhas emitidas e a cada dia geramos mais mil.

rarandrade

@Vera

Que bom q pude te ajudar Vera, eu tb estou no aguardo do script de migração dos dados para testar a versão 2.0 pois atualmente tenho um histórico de 570 mil senhas emitidas e fica inviável perder todo esse histórico, sem contar os inúmeros usuários que tenho no sistema. Anote o meu email rarandrade@gmail.com assim podemos trocar algumas figurinha sobre o sistema pois o foco desse grupo aqui esta voltado somente para versão 2.0.

Abraço

rogeriolino

@rarandrade a questão nem é que está voltado somente para a versão 2.0, mas sobre incentivar a migrar, incentivar a mais gente participar, ajudar nesse script de migração. Até porque a versão 1.x está abandonada, ela está presa na versão 5.6 do PHP enquanto estamos na versão 7.2.

A versão 2.0 foi reescrita usando um framework robusto, bem difundido, até para facilitar contribuições, mas infelizmente continua só eu desenvolvendo. E por isso vocês que participam do fórum, respondendo, ajudando, são muito importante para o projeto.

Vera

@rarandrade o script de migração é apenas uma questão de tempo, em breve teremos um.
Quero migrar para a nova versão, pois é para frente que se anda.
Além disso, pelo que o @rogeriolino já explicou tempos atrás, a versão 2 trabalha de forma diferente, com os acessos ao banco de dados e ao servidor otimizados.

Vera

@rogeriolino e @rarandrade estou saindo de férias na próxima semana e ao retornar pretendo reservar um tempo para estudar a migração de dados.

Por acaso já existe um 'de / para' das tabelas e campos?

Na versão 1.5.1 são 30 tabelas com 158 campos no total. Nem todos campos precisam ser migrados, por exemplo os do atendimento do dia (são transferidos para a tabela histórico ao reiniciar as senhas toda madrugada) e a que controla o painel de senhas chamadas no dia.

Aqui identifiquei que basicamente preciso migrar apenas 17 tabelas pois 10 estão vazias e 3 são zeradas no final do dia (painel_senha, atendimentos e atend_codif).

O que deve dar trabalho é entender a alteração na estrutura de serviços, subserviços e unidades que li em algum lugar que mudou.

Infelizmente na versão 1.5 as colunas não possuem o COMMENT para indicar o significado do conteúdo, e nem sempre o nome do campo é o suficiente para o entendimento.

Se alguém puder enviar a lista de tabelas e campos da versão 2, será o primeiro passo para se construir o script de migração.

-- lista de tabelas
SELECT * FROM information_schema.tables t
WHERE t.table_schema = 'sga'
and t.table_type != 'VIEW'
order by t.table_name

-- lista de campos das tabelas
SELECT * FROM INFORMATION_SCHEMA.COLUMNS c
where c.TABLE_SCHEMA = 'sga' and c.TABLE_NAME not like 'view%'
order by c.TABLE_NAME,c.ORDINAL_POSITION

rarandrade

@rogeriolino e @Vera

Eu sei que a versão nova veio para melhorar o programa, e tenho em mente isso mas como falei no momento não posso abandonar tudo que tenho no anterior e começar do zero na versão 2.0.

Quanto ao script de migração eu estou disposto ajudar não sei se o @rogeriolino tem alguma documentação do escopo do banco de dados se tiver podia disponibilizar para que possamos estudar o que mundo na versão nova para anterior para ver a melhor forma de fazer a compatibilização dos dados.

Vera

@rogeriolino e @rarandrade que tal abrir um novo item 'Migração dados 1.51 para 2.0'?

Só vou poder colaborar após 15/Outubro quando eu retornar das férias.

rogeriolino

@Vera dá para gerar as alterações a partir do doctrine (bin/console doctrine:schema:update --dump-sql). Exemplo: https://pastebin.com/XbxPHnHC

(Esse diff aí não é 100% porque o banco original já sofreu alteração mas é um começo)

@rarandrade não tenho documentação do escopo do banco de dados.

rogeriolino

@Vera tópico criado: https://discuss.novosga.org/d/163-migra-o-dados-1-5-para-2-0

Vera

@rogeriolino obrigada por criar o tópico para a migração, registrei os itens que já analisei.
Aguardo contribuições dos outros participantes.

fielcomunista

Utilizo a versão 7.1 do PHP com a versão 1.5.1 do Novo SGA já há algum tempo e não tive quaisquer problemas.
Entendo a versão 2.0 como natural, mas a migração para ela não faz mais parte dos nossos planos em Santo André. Por aqui teremos que fazer uma reestruturação nos códigos e tabelas do banco para atender a demandas específicas.
Sempre lembrando que se não fosse esse projeto sensacional e o Rogério Lino, em especial, nada do que temos aqui seria possível!