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!