MsSQL:
FROM Clientes
ORACLE:
FROM Clientes
WHERE RowNum <= 10
MySQL:
FROM Clientes
LIMIT 10
MsSQL:
ORACLE:
MySQL:
Já me ocorreu algumas vezes de, ao tentar estabelecer uma conexão contra a base de dados, receber esse retorno. Eu checo e re-checo a connection string e tudo parece estar correto. No Firewall a porta 1433 está devidamente liberada. Nas configurações do SQL Server, os protocolos para a rede, habilitados. Tudo certinho.
Hoje me ocorreu um caso ainda mais inusitado. Criei duas conexões contra a mesma base SQL Server 2005. Uma usando o provedor SqlClient e a outra usando o OleDb. Mesmo usuário, mesmo senha, mesmo tudo. A que usava o SqlClient foi, a OleDb não. Fiquei cabrero.
Depois de um pouco apanhar, resolvi tentar o DNS ou IP para me referenciar ao servidor. Já que a conexão estava sendo feita para um SQL Server instalado na própria máquina, havia tomado a liberdade de usar a constante (local) como nome de servidor.
Buzz’s Eye… Na mosca… Foi só usar o DNS (ou IP) da máquina no lugar de usar a constante que o OleDb se localizou.
“Como provocar um erro SQL Server ?” Essa foi a pergunta do meu amigo. Achei válido catalogar aqui pois além de não precisar me lembrar, pode ser uma dúvida de outros. Eis a resposta:
– OU ALGO ASSIM NUMA PROCEDURE
if AlgumCoisa = SeiLaQue begin
RAISERROR (‘Faz direito que funciona.’, 16, 1)
end
Muitas vezes me questionam sobre como proceder com consultas envolvendo campos data. Bem, em linhas gerais podemos dizer que, fazendo a consulta utilizando o padrão ‘yyyy-mm-dd’ ou ‘yyyymmdd’ ( sendo [y]ear, [m]onth, [d]ay, respectivamente ) não teremos problemas.
Bem, não é bem assim, para que a sintaxe acima funcione, o servidor (e usuário logado) precisa estar utilizando o idioma inglês. Agora, e se o servidor tiver sido instalado com idioma em português, ou ainda, uma aplicação que antes funcionava pois estava em um servidor cujo idioma era inglês e fora restaurado num servidor cujo idioma seja português. Para esses casos precisaríamos de uma instrução para alterar o idioma, o script abaixo faria o serviço.
– DEFINIR O IDIOMA PARA CADA LOGIN DO SERVIDOR
EXEC sp_defaultlanguage ‘sa’, ‘us_english’
– EXEC sp_defaultlanguage ‘NomeUsuario’, ‘us_english’
– EXEC sp_defaultlanguage ‘Maquina\Usuario’, ‘us_english’
– COMANDO PARA RECONFIGURAR ALTERACOES FEITAS
RECONFIGURE
– APOS ISSO SERA PRECISO DAR UM STOP e START NO SQL SERVER
até a próxima.
Muitas vezes, me deparo com o problema de ter uma lista de valores (contida numa string, por exemplo) e querer utilizá-la como registros de uma tabela, talvez para fazer join com alguma outra tabela ou coisa assim. Se essa necessidade ocorrer dentro de uma PROC, poderíamos criar uma tabela temporária, abastecê-la com os registros desejados, fazer uso da forma que desejarmos e depois apagá-la. Já numa VIEW não temos como criar objetos, apenas os consultamos, ou numa rotina dentro de um programa, as limitações seriam semelhantes.
Foi pensando nisso que eu dei uma estudada e cheguei no script abaixo. Ele cria na base de dados uma FUNCTION que recebe por parâmetro uma string contendo a lista de valores e outro contendo o caractere usado como separador na lista e retorna uma tabela com uma coluna e os diversos valores em forma de registros. Vamos ao script:
WHILE @PosIni < Len(@Valores) + 1 BEGIN
IF @PosFim = 0 BEGIN
SET @PosFim = Len(@Valores) + 1
END
INSERT INTO @Retorno (Valor)
VALUES( SUBSTRING(@Valores, @PosIni, @PosFim – @PosIni) )
SET @PosIni = @PosFim + 1
SET @PosFim = CharIndex(@Separador, @Valores, @PosIni)
END
RETURN
END
Supondo que temos a seguinte lista: ‘azul|verde|branco|preto’, podemos ver que os valores são separados pelo caractere: ‘|’ ou seja, faríamos a chamada da função da seguinte forma:
E o retorno seria:
po-po-por hoje é só pe-pe-pessoal… até a próxima
Ao longo dos anos (sim, esse que vos escreve tem algum tempo envolvido com o mundo do desenvolvimento), tenho acumulado em minha maquina muitos PDFs de dicas e tutoriais sobre uma ou outra tarefa que tive de pesquisar na web para conseguir executar e, para não ter de sair pesquisando tudo de novo (visto que minha memória é RAM, desligou apaga), costumo guardar tudo. Vamos aproveitar esse espaço aqui no blog do SQL Lite para divulgar essas dicas tanto de uso do programa como principalmente da linguagem T-SQL em geral.
Para começar, um assunto que me questionam ao menos uma vez por mês:
_ Instalei meu SQL Server e não defini uma senha para o usuário SA, tem como definir depois de instalado ?
Ou então:
_ Descobriram a senha do SA de meu servidor, como faço para alterá-la ?
Bem gente, alterar essa senha é fácil, basta executar a instrução abaixo que, aliás, é a mesma para alterar senha de qualquer usuário:
Até a próxima.
Outra dúvida comum é:
“Rodei um script logado na base com determinado usário, e o script não especificava o owner (dbo, por exemplo). Agora os demais usuários para poderem se referenciar ao objeto criado, precisam especificar meu usuário na frente do nome do objeto.”
Típico, o camarada está logado como JOAO na base de dados e roda um CREATE TABLE Clientes. A partir daí, as consultas à tabela precisam ser feitas especificando o usuário proprietário do objeto (owner), algo como: SELECT * FROM JOAO.Clientes.
Agora, se o João tivesse rodado a querie: CREATE TABLE dbo.Clientes, os demais usuários poderiam se referenciar à tabela simplesmente pelo nome da mesma: SELECT * FROM Clientes.
Mas agora é tarde, o objeto já fora criado, como podemos alterar o proprietário do objeto ? A querie abaixo resolve o problema:
Lembrando que isso serve para Tables, Views, Procedures, Functions, etc.
Editado:
Conforme solicitado, abaixo uma dica de como proceder para executar o processo para diversos objetos de uma única vez. Primeiramente vamos montar uma querie para listar todos os objetos.
Dessa forma teríamos uma lista de todos os objetos, isso inclui TABLEs, VIEWs, PROCs, até mesmo TIGGERs, PKs, etc. Se quisermos filtrar apenas algum(ns) tipo(s) de objeto(s) precisamos incluir condições where na query acima, por exemplo; xType=’U', traria apenas User Tables (tabelas que não sejam de sistema), xType=’V’ apenas views, xType=’P’ apenas procedures, e assim por diante.
Uma vez listado os objetos desejados, vamos filtrar apenas aqueles cujo owner seja diferente de dbo e acrescentar o retorno de uma coluna que irá trazer, para cada objeto, a instrução montada para ser executada.
O retorno dessa querie, devemos exportar para um TXT (da forma que achar mais prático), copiar e colar (apenas a coluna instrucao) de volta em uma outra janela do SQL Lite (ou a ferramenta que estiver usando) e executar.
Espero ter ajudado. Qualquer dúvida ou sugestão, comentem.