Erro com table function em subquery

Hoje caiu em minhas mãos uma tarefa que aparentemente era simples, mas que acabou dando um pouco mais de trabalho do que o imaginado.
A questão era a seguinte: Criar uma query, aonde uma subquery no select, era o retorno de uma subquery, que utilizava uma table function.
Algo parecido com isso:

SELECT
(SELECT [Status] FROM dbo.TableFunction(a.Id))
FROM Tabela1 a

Exemplicando melhor:

CREATE TABLE Teste
(
	ID INT IDENTITY(1,1)
)


INSERT INTO Teste DEFAULT VALUES
GO 50

CREATE FUNCTION dbo.ReturnId(@Id INT)
RETURNS TABLE
AS
RETURN
(
SELECT * FROM Teste WHERE id = @Id
)


SELECT a.Id,
(SELECT Id FROM dbo.ReturnId(a.Id))
FROM Teste a


Coisa que até o momento, era bem tranquilo, problema era que, o erro:


Msg 102, Level 15, State 1, Line 2
Sintaxe incorreta próxima a ‘.’.

Ou

Msg 102, Level 15, State 1, Line 2
Incorrect sintax near ‘.’.

Me aparecia todas as vezes.

De primeira imaginei que seria algum problema com algum SET, ou seja, alguma configuração de sessão….

Estava errado, descobri, junto com um amigo depois, que o problema estava no nivel de compatibilidade da base, como haviamos migrado recentemente para o SQL Server 2008, a base estava com compatibilidade 80, portanto a unica solução encontrada foi alterar o nivel da base para 100, como ja haviamos verificado se a aplicação funcionaria em SQL Server 2008, não houve problema, mas tomem cuidado ao realizar essa operação!

Anúncios
Post a comment or leave a trackback: Trackback URL.

Comentários

  • Alexandre.  On 07/12/2011 at 21:42

    Me disseram que mudar o nível de compatibilidade da base pura e simplesmente pode dar problema.

    Pelo que me contaram, para fazer upgrade de uma base direito tem que criar a base do zero criar os objetos via Script e depois importar os dados, isso é verdade ?

    • fabrizziocaputo  On 07/12/2011 at 23:50

      Alexandre,

      1 – Sim, sem pensar, alterar o nivel de compatibilidade de uma base sera um problema, final de semana retrasado, estavamos em uma migração, e mesmo depois de ter feito tudo que explicarei mais a frente, uma query passou sem que tenhamos percebido, no caso, estavamos fazendo o upgrade do SQL Server 2000 para o SQL Server 2008R2, a query era algo parecido com isso:
      SELECT Id, *
      FROM Tabela
      ORDER BY Id

      E estavamos sempre tendo erro de coluna com nome ambiguo, e isso faz sentido, mas infelizmente essa era uma brexa que funcionava no SQL Server 2000, como estavamos fazendo um upgrade side by side, não precisamos alterar o nivel de compatibilidade, uma vez que adiamos a atualização essa alteração foi feita em aplicação, porem, imagine se a base ja estivesse em produção com SQL Server 2008R2 e nivel de compatibilidade 80, e alterassemos para nivel 100? Com certeza iria dar erro, causando impacto na aplicação, então sim, alterar o nivel de uma base é extremamente arriscado e deve-se tomar muito cuidado.

      Existem problemas tambem em abaixar o nivel de compatibilidade, por exemplo, apesar do data type VARBINARY(MAX) não estar disponivel no SQL Server 2000, uma base com nivel 80 em uma instancia SQL Server 2008, aceitara este tipo, porem não aceitara o PIVOT TABLE, estranho? Sim, existem algumas outras features que apesar de estarem em uma instancia superior, devido ao nivel de compatibilidade, não irão funcionar.

      2 – Apenas criar o script dos objetos e dos dados não é uma atualização, e apenas isso não ira garantir de forma alguma um upgrade seguro, algumas pessoas tem isso em mente, devido ao fato de ja terem passado por migrações, aonde o pós migração estava mais lento que antes, mesmo em HardWare e SoftWare melhor, portanto, como dica, sempre depois de um upgrade, realizar um UPDATE STATISTICS WITH FULL SCAN, isso ira garantir que uma base com um modelo X de estatistica para um HardWare e SoftWare obsoleto, sejam refeitas completamente do zero, melhorando assim sua performance, principalmente quando ha mudança fisica na arquitetura, exemplo: de x32 para x64.

      Ao realizar o script dos objetos e dados, voce pode de forma simples, pegar um backup e restaurar, que dara muito menos trabalho, mas isso só funciona para upgrade, para downgrade, não sera possivel isso, então ai sim sera necessario gerar os scripts, por uma questão de administração interna do SQL Server, mas não como garantia de migração segura.

      O que voce deve fazer para garantir uma migração segura (Não entrarei em detalhes para explicar upgrade in place ou side-by-side, apesar dos nomes serem bem claros rs…):
      – Executar o upgrade advisor
      – Capturar durante alguns dias um trace em back ground, preparar um ambiente como o futuro, criar uma base a partir do backup, e realizar um replay deste arquivo, assim voce fara com que o SQL Server execute todos os comandos novamente, caso de algum erro, voce ira perceber na hora.
      – Como gosto pessoal, gosto de executar algumas coisas manualmente, uma vez que a linguagem TSQL segue alguns padrões ANSI, um select ou update raramente darão problemas, porem, features exclusivas do SQL Server, como data types images, text…. seria bom executar manualmente, no caso deste até alterar, porem querys que não fazem parte da regra ANSI, eu gosto de executa-las em um ambiente de testes para a migração.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: