Hih Nojeeento

Comentário de Diego Nogare em 25 novembro 2008 às 23:04

Em uma procedure, foi utilizado o recurso de INSERT com SELECT.
Até ai, nenhum problema... Só que os dados do SELECT as variaveis que foram passadas por parametro para a proc...

O comando era parecido com isso:
INSERT INTO tabela1(campo1, campo2)
SELECT @campo1, @campo2

Hih Nojeeento!

Comentário de Diego Nogare em 25 novembro 2008 às 23:09

Reparem onde o rack com os switchs ficam... Como diz o grande craque Neto: "É brincadeira uma coisa dessa"

Depois a rede para, e colocam a culpa no coitado do cara do suporte!!!

Comentário de Daniel Granero em 26 novembro 2008 às 22:39

Bom , essa vem do mesmo lugar e projeto que o Diego mencionou...
Tem "material" pra mais de 1 mês lá, mas tem uma em especial que chamou minha atenção:
Em uma tela de pesquisa do cadastro principal do sistema, após o usuário informar os parâmetros e clicar no botão para pesquisa, há um código que coleta a informação de todos os campos dos filtros e adiciona a um Objeto. Até aí tudo bem certo? Certo só até esse ponto, porque em vez de usar as propriedades desse objeto e passar os parâmetros para a procedure, "acharam melhor" criar uma procedure sem parâmetros que retorna todo o conteúdo da tabela para a aplicação e dentro da aplicação já no Datatable é que aplicam os filtros.(ps: criaram a stored procedure ao melhor estilo SELECT * FROM TABELA) (ps2: Fizeram isso na tabela com maior número de campos e de registros do sistema)

Resumo da Ópera: Por Exemplo, se imaginarmos uma tabela com 10.000 registros, em vez de executarem uma query direto na base que retorne 3 registros, preferem trafegar os 10.000 registros da base para a aplicação para depois executarem uma query no DataTable e retornar os 3 registros, fazendo a consulta duas vezes.

Eu sei que ninguém é perfeito e todos nós com certeza já erramos, mas se o nosso mestre Tião Macalé estivesse vivo soltaria um belo de um
- IHHH NOJEEENTO!!! TCHAAAAAAANNNNN!!!

Comentário de Mauricio Barcelo da Costa em 3 dezembro 2008 às 19:08

HUa.,...seeeempre...

Apesar de não ser relacionado a "TI" mas o presidente da empresa onde eu trabalho já ligou aos berros pro meu gerente pq ele tava em uma apresentação da empresa para um cliente e o projetor não ligava.

Eñtãaaao...o meu gerente chamou o "Severino" do departamento (este que vos fala) e pediu que eu fosse ajudar.

E realmente o projetor não ligava pq estava Desligado.

Foi uma cena ótima eu chegar lá e simplesmente apertar um botão verdinho. Sò faltou aquela luz divina vinda do céu e o coral de anjinhos ao fundo....

Totalmente BIZAAAARRO

Comentário de Diego Nogare em 10 dezembro 2008 às 23:39

Fala Galera...

Mais uma vez, postando um TCHAN!!!!

Em algumas procedures de insert que eu vi esses dias atrás, era necessário retornar o ID do registro inserido. Até este momento, é tudo bem tranquilo pra se fazer... Porém..... Quando eu ví o código, quase gorfei! rs

O quadrupede que escreveu a procedure ao invéz de usar o @@IDENTITY para retornar o ID do registro inserido, faz um SELECT MAX(ID)...

São essas coisas que gostamos de ver e pensamos...Hih Nojeeento!

Comentário de Diego Nogare em 22 dezembro 2008 às 16:17

Pra continuar com a sequencia bizarra que eu vejo em vááários lugares que passo... Olha esta "NORMALIZAÇÃO" de Banco de Dados.

Está lindo isso, visto que cada paragrafo que gera o relatório está em fixo no Banco e se precisar alterar o texto de algum paragrafo ou adicionar um novo será preciso chamar o Diego pra fazer esta alteração... Isso é mais $$$$$ pro bolso do Diego... Sensacional!

Comentário de Eduardo Cucharro em 6 janeiro 2009 às 11:52

E ae galera, blz?
Em um dia normal de trabalho, programando feliz e contente me deparei com uma situação nova. Posso eu vincular um enum como datasource de um controle asp.net?
Bom, fiz aquela tradicional pesquisa e olha só a gamba que encontrei:

enum ContractType
{
Permanent = 1,
Contract = 2,
Internship = 99
}

public static Hashtable BindToEnum(Type enumType)
{
// get the names from the enumeration
string[] names = Enum.GetNames(enumType);
// get the values from the enumeration
Array values = Enum.GetValues(enumType);
// turn it into a hash table
Hashtable ht = new Hashtable();
for (int i = 0; i < names.Length; i++)
// note the cast to integer here is important
// otherwise we'll just get the enum string back again
ht.Add(names[i], (int)values.GetValue(i));
// return the dictionary to be bound to
return ht;
}

MyDropDownList.DataSource = BindToEnum(typeof(ContractType));

Até que um ser de bom senso viu a cagada e postou em resposta:

MyDropDownList.DataSource = Enum.GetNames(typeof(ContractType));

Hiii nojento. :D

Comentário de Richard Mathias em 20 janeiro 2009 às 20:17

Fala pessoal tudo bem?

Sempre tem um cara que não é de T.I. mas é metido a ser o bonzão dos computadores aí esse cara viu um arquivo com a extensão .eml no pc do dono da empresa e disse que esses arquivos são vírus e falou para apagar todos...
E não é que o dono começou apagar tudo que era .eml !!! Só que nessa época todo mundo utilizava Outlook Express.
Resumindo, ele apagou todos os e-mails. E digo mais foi lá no servidor e apagou tudo por lá tb... com isso muita gente perdeu todos os e-mails....

Comentário de Diego Nogare em 26 janeiro 2009 às 16:40

Tchan!!! Olha a arte....

Um certo MVP de SQL Server que também é consultor independente, precisou fazer uma alteração em uma PROC. A alteração consistia em fazer um While e criar uma linha com informações...

Depois da alteração, o sistema não funcionava mais... Neste momento, o referido MVP decidiu pensar no que poderia ter parado o banco. Foi então que lembrou que tinha feito um WHILE.

A primeira coisa que fui procurar, era se tinha colocado o incrementador do WHILE, para minha surpresa eu tinha feito o incremento... Quando olhei pra cima, na condição eu gritei:
- Hih Nojeeento!!!

Hahaha. a barberagem foi que a condição era sempre verdadeira... Eu não tinha colocado a variavel correta como limitador...

WHILE (@contadorFielEmitente <= (@contadorFielEmitente)
BEGIN

SELECT @TEXTO_FINAL = @TEXTO_FINAL + ' o Sr(a) ' + nome + ' inscrito no CPF/MF N° ' + cpf + ' e '
FROM #tmpNomeFielEmitente
WHERE id = @contadorFielEmitente + 1

SET @contadorFielEmitente = @contadorFielEmitente + 1
END

Depois disso, corrigido o WHILE a aplicação "misteriosamente" voltou a funcionar normalmente...

Este tal MVP sou eu... ahahahaha

Comentário de Diego Nogare em 20 março 2009 às 11:45

Eu não aguento mais ver esse tipo de coisa no projeto atual que estou...

Uma certa artezã desgraçada (é sério, fiquei sabendo que a figura que fez o sistema possui um ateliê de artezanato!!!), usa Session para tudo o que se imaginar.

Para carregar informações que são acessiveis via banco, não foi diferente, ela transforma os dados de tabelas em XML e carrega em uma Session.

Esta é de doer!

Comentar

• ‹ Anterior
• 1
• 2
• 3
• Próximo ›
• Página