quinta-feira, 9 de outubro de 2014

SQLServer 2008 - Reset do valor de uma sequência de uma campo Entity

Por vezes, quer por questões de migração de dados, updates ou outros casos, é preciso redefinir ou alterar o valor atual do gerador de números sequênciais para um determinada coluna de uma tabela numa Base de Dados. No caso do SqlServer 2008, não existe o conceito de SEQUENCE tal como em outras BDs (Oracle, etc...), mas existe algo minimamente equivalente que é o tipo Entity atribuído a uma única coluna da tabela em questão. O facto de só poder existir uma coluna/campo com o tipo Entity, acrescido do facto de não se poderem manipular as sequencias isoladamente como um objecto normal da BD, são as maiores diferenças desta implementação face a outras BDs. Assim, sendo como fazer, quando se quer alterar a sequência (o próximo id/Entity) a ser gerado ?
DBCC CHECKIDENT( 'nome_do_schema.nome_da_tabela', reseed, novo_numero_de_sequencia );
Se quisermos por exemplo fazer reset da sequência de forma ao próximo registo inserido ter a coluna/campo Entity com o valor 10000, deveremos executar o comando, de forma a configurar a sequência para o número anterior, dado que a sequência guarda o último número gerado, gerando o seguinte a partir desse mais o incremento definido. NOTA: Ter atenção nos casos em que o incremento da sequência não foi definido como 1, pois ai o próximo número será o número guardado na sequência mais o incremento definido. Assumindo então um schema com o nome "schema_teste" e uma tabela de nome "tabela_teste", para uma nova sequência da coluna/campo entity a começar em 10000, executariamos o seguinte comando.
DBCC CHECKIDENT( 'schema_teste.tabela_teste', reseed, 9999 );
AVISO: Obviamente, se uma sequência for alterada de forma a que possa gerar IDs idênticos a registos que já existam, irão surgir erros relativos à UNIQUE CONSTRAINT que é definida implicitamente para uma coluna/campo do tipo Identity. Habitualmente aumenta-se o número da sequência, e só em casos especiais se reduz, devido a necessidade de garantir a unicidade do identificador (Identity).

quinta-feira, 21 de agosto de 2014

Firefox URLEncode Feature

Hoje, dei-me conta que o Firefox (versão 31.0), tem uma feature (funcionalidade), que pode ser bastante prática/util para um developer, nomeadamente fazer o URL encode de qualquer texto que se introduza no campo de endereço. Por exemplo: Escrever ou fazer copy&paste do seguinte:
http://www.google.com/olá.olé.olí
Se a seguir selecionarem o endereço (Ctrl+A ou usando o rato) e copiarem o seu conteúdo (Ctrl+C), quando fizerem Paste (Ctrl+V) por exemplo no notepad ou semelhante, vão ver a String original URL encoded. Para o exemplo anterior será:
http://www.google.com/ol%C3%A1.ol%C3%A9.ol%C3%AD
Sempre é mais rápido do que ir pesquisar um site na net, para fazer o mesmo. Ou para os mais geeks, chamar a funcão javascript para fazer o encode directamente no campo do endereço.
javascript:encodeURI("www.google.com/olá.olé.olí")

quinta-feira, 10 de abril de 2014

Descobri um problema irritante com o IE7/8, e a sua implementação de AJAX.
Basicamente, se usarem JQuery, para fazer pedidos ao servidor, estes são feitos, usando o charset "UTF-8", e está documentado. Funciona correctamente se usarmos browsers considerados "normais", como: Firefox, Chrome, etc... mas no caso do IE não podia ser assim não é verdade ...
No caso do IE7, o pedido vai para o servidor e leva o "header" ("Content-Type:") correctamente definido, mas o IE7, simplesmente não faz a conversão dos dados para o formato correcto.
Para funcionar em IE7/8, é necessário forçar o contentType na chamada ajax do JQuery, semelhante a isto:

$("form#myForm").ajaxForm(
 {
  contentType: 'application/x-www-form-urlencoded; charset=UTF-8',
  success:
   function( data )
   {
    alert( 'success' );
   }
 } );

WebGl no Firefox

Como ativar o WebGl no Firefox. Os passos são simples:
  1. Aceder a "about:config" na barra de endereços
  2. pesquisar por "webgl", na página "about:config"
  3. alterar ou verificar que as seguintes configurações estão a "false"
    • webgl.disabled
  4. alterar ou verificar que as seguintes configurações para "true"
    • webgl.force-enabled
    • webgl.force-layers-readback (algumas aplicações precisam deste setting)
    • webgl.prefer-native-gl (optimização)
NOTA: Para alterar uma configuração basta fazer double click. Algumas aplicações para testar se o WebGl está ativo e a funcionar.

quarta-feira, 21 de dezembro de 2011

Hoje após duas horas desesperantes, descobri a solução para o problema do scrollTop no IE8, quando é usado dentro de um 'SELECT'.

Basicamente, no IE8 quando se adiciona um elemento 'OPTION', via Javascript a um 'SELECT' que seja do tipo 'multiple' (nota: estou a usar um 'size' de 10), não posiciona a scroll bar, de forma a mostrar o elemento 'OPTION' que foi inserido (já pré-selecionado).

Isto tem o inconveniente de o utilizador não se aperceber que o elemento foi realmente adicionado, se a combo não estiver na posição ideal.

Note-se que estou a inserir os elementos ordenados alfabeticamente, logo a inserção poderá ocorrer em qualquer posição, dependendo dos elementos já existentes e do elemento inserido.

Para corrigir este problema de usabilidade, defini o seguinte código após ter efectuado a inserção no 'SELECT', dentro de um objecto JS que o contém:

   // we have to do this, in order for IE8 to correctly scroll to the added element
if( option.selected)
{
var topScroll = 0;
if( this.select.length )
topScroll = index * (this.select.scrollHeight / this.select.length );

this.select.scrollTop = topScroll; // <=- linha problemática
}


No entanto, após fazer debug da coisa, a 'linha problemática' aparentemente não executa !!!
Isto é, mesmo que o valor topScroll seja diferente de zero, o campo 'this.select.scrollTop' fica intocado.
É como se a instrução nunca tivesse sido executada !!!

Após perder umas centenas de neurónios, reparei que se eu forçar o valor no debugger a correcção funcionava !

Após mais algumas tentativas, para perceber o problema, cheguei ao momento Eureka!

O IE8, pega de empurrão!

Isto é a solução é insistir à canzana ! :)
Ou seja, repetir a instrução de atribuição !

   // we have to do this, in order for IE8 to correctly scroll to the added element
if( option.selected)
{
var topScroll = 0;
if( this.select.length )
topScroll = index * (this.select.scrollHeight / this.select.length );

this.select.scrollTop = topScroll;
this.select.scrollTop = topScroll; // WE MUST DUPLICATE THIS LINE, due to an IE8 Bug !
}


Incrível, mas é verdade ! E assim já funciona como esperado e é inócuo para os outros browsers, como seria de esperar.

quinta-feira, 22 de setembro de 2011

Java decompiler para o Eclipse

O Eclipse Java Decompiler pode dar jeito, quando ao meio do debug, nos deparamos com uma classe de uma lib (jar) qualquer, da qual não temos a source disponível.
Permite fazer o decompile da class enquanto fazemos debug, para determinar a fonte do problema.

terça-feira, 9 de agosto de 2011

IE8 Document Mode é Sticky !

Mais uma "feature" do IE8!
Se tivermos uma página simples, que abrimos em dois tabs, mas no primeiro tab definimos o URL como 'localhost' e o outro tab com o URL com o nome da máquina propriamente dito ("wheat", no exemplo).

Vamos constatar que o IE8, vai fazer o 'render' da página com margin e offset distintos, para a tag BODY.

A página está definida com o seguinte DOCTYPE:
<!-- DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd" -->

Após mais alguns testes, acabei por descobrir que o problema não era do URL, mas sim devido ao facto de ter reutilizado um tab (alterando o seu URL), que conteve anteriormente uma página que forçou o modo de compatibilidade 'IE7' no IE8, com o seguinte meta dado no head !

<meta http-equiv="X-UA-Compatible" content="IE=8"/>

Resumindo e concluindo, o modo de compatibilidade aparentemente é uma propriedade do tab, e que não muda com a alteração do endereço (URL), como devia.

Isto implica que uma página que faça um render correcto, seguindo os standards, pode ficar completamente desfigurada no IE, se o tab tiver sido usado para aceder a outra página previamente, que tenha forçado o modo de compatibilidade do IE.