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
4 dias depois

@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

    6 dias depois

    @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();

    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 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.

    @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

    @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.

    @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.

    @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

    @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.

    @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.

    @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 obrigada por criar o tópico para a migração, registrei os itens que já analisei.
    Aguardo contribuições dos outros participantes.

    8 meses depois

    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!