@rarandrade
obrigada! Vi que são 30 tabelas.

@rogeriolino
devemos ter algum cuidado especial ao comparar estrutura MySQL com PostgreSQL?
Já existe um manual ou um local onde seja possível conhecer as telas / funcionalidades da versão 2.0? Não localizei esta informação no http://novosga.org/docs/current/

Vi que tem uma tabela 'agendamentos', estou interessada em conhecer este item, pois uma de nossas unidades tem esta necessidade e isto pode significar agilizar nossa migração para a versão 2.0...

    @rogeriolino
    apesar de não conhecer as telas da versão 2.0, tentei fazer uma análise inicial usando como referência apenas os nomes das tabelas. Você pode validar ou enviar um link onde eu possa obter mais informações?

    Coloquei ??? nas tabelas em que estou com dúvidas.

    Não localizei uma tabela da versão 2.0 equivalente à tabela oauth_scopes da versão 1.5.1.
    Por acaso as tabelas 'oauth' são as que contém os dados de integração com outras aplicações via API web do sistema? Como na Prefeitura não usamos, nossas tabelas estão vazias. Imagino que neste caso estas tabelas também não seriam migradas, bastaria fazer a configuração pela aplicação.

    Aguardo a revisão desta etapa de identificação das tabelas para poder iniciar a parte de análise dos campos.

    Obrigada.

    Os dados abaixo possuem tabulações, se quiser uma tabela formatada, copie e no Excel use a opção 'colar especial / texto'.

    Tabela versão 2.0 = Tabela versão 1.5.1
    agendamentos = NOVA
    atendimentos = atendimentos
    atendimentos_codificados = atend_codif
    atendimentos_metadata = atend_meta
    clientes = NOVA - CLIENTES AGENDADOS???
    contador = contador
    departamentos = grupos ???
    historico_atendimentos = historico_atendimentos
    historico_atendimentos_codificados = historico_atend_codif
    historico_atendimentos_metadata = historico_atend_meta
    locais = locais
    lotacoes = usu_grup_cargo + cargos_mod_perm???
    metadata = NOVA - config + modulos???
    migration_versions = NOVA - QUAL FINALIDADE???
    oauth_access_tokens = oauth_access_tokens
    oauth_clients = oauth_clients
    oauth_refresh_tokens = oauth_refresh_tokens
    ??? = oauth_scopes
    paineis = paineis
    paineis_servicos = paineis_servicos
    painel_senha = painel_senha
    perfis = cargos
    prioridades = prioridades
    servicos = servicos
    servicos_metadata = serv_meta
    servicos_unidades = uni_serv
    servicos_usuarios = usu_serv
    unidades = unidades
    unidades_metadata = uni_meta
    usuarios = usuarios
    usuarios_metadata = usu_meta

      @rogeriolino

      Vc chegou a testar o painel web usando o sistema com banco Postgres, eu não consigo fazer rodar o painel de jeito nenhum cadastro dentro de WEB API client ele gera o public_id e o Client Secret, mas quando insiro essas chaves no painel aparece sempre a mesma msg

      "Oops!
      Bad Request: The client credentials are invalid"

      E se executo o Force reload aparece essa msg

      "Oops!
      Unauthorized: The access token provided is invalid."

      Dependo de fazer o funcionar o painel para conseguir testar bem o sistema para tentar ajudar na migração dos dados

      6 dias depois

      Vera

      As tabelas OAuth não precisa migrar.

      Clientes é a tabela para guardar os dados dos clientes que antes eram salvos direto na tabela de atendimentos. Agora ao invés de replicar os dados, faz a associação. Assim também é possível fazer integrações e relatórios.

      Departamentos é uma nova entidade utilizada para agrupar serviços. É útil na triagem-touch. E para futuros relatórios.

      Metadata seria a antiga tabela config. São metadados globais do sistema.

      A tabela migration_versions é de controle do Doctrine Migrations, serve para controlar a execução dos scripts de migração para futuros upgrades.

        Vera não precisa se preocupar com banco. Fazendo o script para um será fácil adaptar para o outro.

        A documentação da v2.0 ainda está bem limitada.

        Essa tabela agendamentos serve para integrar com algum sistema de agendamento, caso possua. É possível vincular o atendimento gerado a um registro nessa tabela.

          22 dias depois
          3 meses depois

          @rogeriolino você tem o sga 2.0 com as dependencias instalado amigo, pode liberar pra nos amigo porque não estou conseguindo instalar ele pode liberar pra nos amigo NOVOSGA 2.O FINAL

          3 meses depois

          Boa tarde! Alguém já criou um script para migração dos dados?

          2 meses depois

          rarandrade estou com o problema do painel do sga 2.4 no Windows não estou conseguindo configurar poderia me ajuda ? os mesmos erros que estava acontecendo com você estão comigo.

              7 dias depois

              ayrton Desculpe a demora para responder, verifique se não esta com espaço no final do client_secret e no public_id, não sei por que no momento que eu esta copiando os dados eles esta copiando um espaço no final.

                9 meses depois
                um mês depois

                Olá, apenas atualizando...
                Há alguns meses passamos a copiar diariamente os dados do NovoSGA para o banco de dados de um sistema interno de BI onde são feitos relatórios e gráficos de análises mais detalhados do que os oferecidos pelo NovoSGA.
                Continuamos a usar a versão 1.5.1 com MySQL e ambiente Linux que nos atende bem desde maio/2017.
                Como temos os dados no sistema de BI, definimos que quando viermos a mudar de versão não faremos a migração do banco de dados, apenas vamos adaptar as views usadas para copiar para o BI.

                  3 anos depois

                  Vera Boa tarde, pode deria me ajudar com algum docuemento de como fez para utilizar o banco em um BI?

                    un ano depois

                    Boa tarde. Alguém fez o script de migração ou poderia dar um exemplo da estrutura dele?

                    9 dias depois

                    Também estou com a mesma necessidade de migração. Não encontrei nada pronto ainda para migrar o banco do SGA, mas vi que existem ferramentas que possibilitam fazer esta ação, como usar Python com Pandas e SqlAlchemy, criando um script poderoso que consegue migrar e fazer transformação de grandes massas de dados, acredito que seja uma direção para fazer uma implementação. Também pensei em rodar uns comandos de drop, update e create numa cópia do banco antigo de forma que ele possa ser atualizado para o formato do schema do novo banco.
                    Outra abordagem que acredito ser possível, se a massa de dados não for muito grande, seria exportar para csv o db antigo, fazer alterações no arquivo de modo a permitir sua importação no db novo.