NUMERO DE OR?AMENTO DÊVIDA BASICA PK
0000 [Sequencial] + 12 [Mes] + 2015 [Ano].
Então o primeiro orçamento de Dezembro 2015 será:
0001 12 2015
Estou passando pra .NET qual a melhor forma de recuperar esse numero? Sei quem em POG (Orientado a GATOS) é só usar Select Max no numero sequencial (nao é autonum) e somar + 1, depois dar um select ver se existe, caso nao existir insere, pois o numero do orçamento deve ser mostrado apos o vendedor clicar em [Ô]novo orçamento[Ô]..
O correto é usar Last_insert_id correto? más o Last_Insert_Id funcionaria corretamente em um campo sem auto_increment??
Grato!
Citação::
Qual banco de dados está usando?
Opa Kerplunk, uso o banco MySQL, só reiterando o numero sequencial não precisa zerar a cada virada de mês, então em janeiro de 2016 o sequencial sera:
dia + mes + ano
00004 01 2016
e ai vai contando o sequencial até dezembro por ex:
09999 12 2016 .
Citação::
se usar um autoincrement apenas pro automático, e numa segunda coluna salvar mês+ano, qq coisa vc pode recuperar do campo e usar substring pra separar esses 6 dÃgitos [Ô]fixos[Ô] fora do autoincrement....
tambem ja tinha pensado nessa possibilidade, porém o número sequencial deve zerar a cada ano novo.. por ex: 01 / 2016 terá que ter o Orçamento 00001 01 16
sem contar também que a tabela no banco já está totalmente populada com mais de 300 mil registros sem auto_increment.
Talvez uma solução que margeie o mundo das [Ô]gambis[Ô], mas você não poderia ter uma tabela de anos com dois campos, sendo um autoincrement?
Algo como:
Tb_Num_Orc
Sequencial: autoincrement
Ano: smallint
Verificando a data atual você só busca na tabela pelo próximo sequencial de acordo com a coluna [Ô]ano[Ô].
Tudo de bom!
Citação::
Colega,
Talvez uma solução que margeie o mundo das [Ô]gambis[Ô], mas você não poderia ter uma tabela de anos com dois campos, sendo um autoincrement?
Algo como:
Tb_Num_Orc
Sequencial: autoincrement
Ano: smallint
Verificando a data atual você só busca na tabela pelo próximo sequencial de acordo com a coluna [Ô]ano[Ô].
Tudo de bom!
Entendi, más concorda que se eu jogar um auto_incr em 2016 quando tiver que [Ô]zerar[Ô] a contagem irá duplicar as primary key auto_incr?? pois eu não posso deletar os registros antigos portanto terão 2 sequencias 01 gerando duplicidade de chave primaria e se eu não zerar chegará um momento que ficara orçamentos gigantes e é uma norma da empresa [Ô]zerar[Ô] a numeração a cada ano e manter os antigos, sem contar que devo respeitar a base de dados que já existe.. é complicado talvez terei de fazer essa POG, qual o risco de eu fazer uma POG do Jedi Ioda rei das POG[ô]s pra contar + 1 (select Max+1) no sequencial clicando no botão where ano = @ano clicando no botão [Ô]Novo[Ô] e antes de inserir o registro eu dar um select pra ver se ja existe e caso existir ele chama o método de contar + 1 no sequencial novamente?? Qual o risco de me gerar o mesmo número a 2 vendedores ?
é complicado pois estou batendo cabeça na norma da empresa de zerar a cada ano e nas normas da empresa e também que tenho que respeitar o banco que não é auto_incremento..
a base está assim: OFERTA,CodigoDiaMes
Oferta = Sequencial 00001 (chave primaria não é AI)
CodigoDiaMes = Ano (chave primaria não é AI)
dai o que o sistema faz atualmente, ele gera a numeracao 00001 2016 e não gera duplicidade pois o codigodiames também é uma PK..
Eu diria que você tem um objetivo claro a atingir, que é em cada ano ter um número sequencial.
Nesta linha, é que penso que talvez não seja tão [Ô]pog[Ô] o (select Max+1), de acordo com o cenário que tens (ao menos o cenário que eu entendi ter), creio que seria tua solução ter o select max.
Eu tive caso parecido ao precisar, em uma mesma base de dados, ter um sequencial diferenciado para cada código de empresa, visto serem duas funcionando no mesmo endereço. Eu havia pensado na época em criar duas sequences (postgres). De fato duas sequences resolveria o problema, mas como o sistema não é fechado e eu poderia ter algum cliente que teria 3 ou mais empresas no mesmo endereço, teria que acabar customizando o sistema para cada cliente e isto é mão-de-obra demasiada, perda de tempo, significa perder o controle do padrão e por fim, perder o controle do sistema.
Se pensarmos que o que para mim era empresa (que podem ser 3 ou mais) e para voce são anos (que por óbvio serão mais de 3), os casos se assemelham (eu com empresas e você com anos).
Eu usei uma tabela com código da empresa e campo não autoincrement, funcionando com select max + 1 no momento da gravação. Não ficou uma tabela grande, porque afinal de contas teria apenas dois registros (no seu caso, em 20 anos, teria 20 tuplas/registros). Gambiarra? Pode ser, de acordo com a interpretação. Mas ficou rápido, com tabela pequena e resolveu o problema, podendo ser usado em várias empresas (no seu caso, em vários anos).
Talvez sua solução caminhe pela mesma estrada.
Tudo de bom!
Citação::
Bem, colega...
Eu diria que você tem um objetivo claro a atingir, que é em cada ano ter um número sequencial.
Nesta linha, é que penso que talvez não seja tão [Ô]pog[Ô] o (select Max+1), de acordo com o cenário que tens (ao menos o cenário que eu entendi ter), creio que seria tua solução ter o select max.
Eu tive caso parecido ao precisar, em uma mesma base de dados, ter um sequencial diferenciado para cada código de empresa, visto serem duas funcionando no mesmo endereço. Eu havia pensado na época em criar duas sequences (postgres). De fato duas sequences resolveria o problema, mas como o sistema não é fechado e eu poderia ter algum cliente que teria 3 ou mais empresas no mesmo endereço, teria que acabar customizando o sistema para cada cliente e isto é mão-de-obra demasiada, perda de tempo, significa perder o controle do padrão e por fim, perder o controle do sistema.
Se pensarmos que o que para mim era empresa (que podem ser 3 ou mais) e para voce são anos (que por óbvio serão mais de 3), os casos se assemelham (eu com empresas e você com anos).
Eu usei uma tabela com código da empresa e campo não autoincrement, funcionando com select max + 1 no momento da gravação. Não ficou uma tabela grande, porque afinal de contas teria apenas dois registros (no seu caso, em 20 anos, teria 20 tuplas/registros). Gambiarra? Pode ser, de acordo com a interpretação. Mas ficou rápido, com tabela pequena e resolveu o problema, podendo ser usado em várias empresas (no seu caso, em vários anos).
Talvez sua solução caminhe pela mesma estrada.
Tudo de bom!
Entendi perfeitamente, porém meu grande medo é ocorrer o que ocorreu já uma vez, onde um vendedor roubava numeração de outro.. ou seja se 2 clicassem ao mesmo tempo no botão novo ele geraria 2 numero de orçamentos iguais e um dos vendedores saia no preju, esse é o grande problema de usar o Max+1.. então a solução que pensei foi antes de inserir o Max+1 bater no banco e ver se ele ja existe e caso não exista ele da um Insert.. Porém gostaria de saber quais os riscos de fazer isso
Grato!
Citação:
Entendi perfeitamente, porém meu grande medo é ocorrer o que ocorreu já uma vez, onde um vendedor roubava numeração de outro.. ou seja se 2 clicassem ao mesmo tempo no botão novo ele geraria 2 numero de orçamentos iguais e um dos vendedores saia no preju, esse é o grande problema de usar o Max+1.. então a solução que pensei foi antes de inserir o Max+1 bater no banco e ver se ele ja existe e caso não exista ele da um Insert.. Porém gostaria de saber quais os riscos de fazer isso
Realmente, durante a confecção do orçamento, o número apresentado deve ter caráter meramente sugestivo, tal qual o número de NF (o usuário pode desistir da NF a qualquer momento e para não precisar inutilizar o número depois, tal número é gravado de fato apenas na inserção da NF). O mesmo serve para orçamento.
Sugerir no momento da confecção e finalizar com número definitivo apenas no ato da gravação.
Foi por isto que usei o termo [Ô]no momento da gravação[Ô]
Citação:Eu usei uma tabela com código da empresa e campo não autoincrement, funcionando com select max + 1 no momento da gravação.
Penso que o caminho é este, colega.
Tudo de bom.
Citação::
Colega,
Entendi perfeitamente, porém meu grande medo é ocorrer o que ocorreu já uma vez, onde um vendedor roubava numeração de outro.. ou seja se 2 clicassem ao mesmo tempo no botão novo ele geraria 2 numero de orçamentos iguais e um dos vendedores saia no preju, esse é o grande problema de usar o Max+1.. então a solução que pensei foi antes de inserir o Max+1 bater no banco e ver se ele ja existe e caso não exista ele da um Insert.. Porém gostaria de saber quais os riscos de fazer isso
Realmente, durante a confecção do orçamento, o número apresentado deve ter caráter meramente sugestivo, tal qual o número de NF (o usuário pode desistir da NF a qualquer momento e para não precisar inutilizar o número depois, tal número é gravado de fato apenas na inserção da NF). O mesmo serve para orçamento.
Sugerir no momento da confecção e finalizar com número definitivo apenas no ato da gravação.
Foi por isto que usei o termo [Ô]no momento da gravação[Ô]
Eu usei uma tabela com código da empresa e campo não autoincrement, funcionando com select max + 1 no momento da gravação.
Penso que o caminho é este, colega.
Tudo de bom.
Concordo plenamente, porém tem um grande problema que é a peça atrás do pc, o usuário, aqui eles estão acostumados a clicar o [Ô]novo[Ô] e ver o número do orçamento, como os caras só reclamam eu tenho certeza absoluta que vão reclamar se o número do pedido só aparecer após a gravação..