ChrisF's questions

Tenho alguns dados armazenados em uma tabela em formato XML:

<AccountTypes xmlns="">
  <Id>1003</Id>
  <Id>2</Id>
  <Id>3</Id>
  <Id>1004</Id>
  <Id>1002</Id>
  <Id>0</Id>
</AccountTypes>

Esses são dados herdados que anteriormente eram processados ​​apenas no código C#, portanto, não podem ser alterados.

Agora preciso ler isso e processá-lo em um procedimento armazenado. Até agora tenho o seguinte código:

DECLARE @accountTypes XML
SELECT @accountTypes = DT.AccountTypes FROM dbo.DataTable AS DT
WHERE DT.Id = 1016

DECLARE @hdoc int
    
EXEC sys.sp_xml_preparedocument @hdoc OUTPUT, @accountTypes
SELECT *
FROM OPENXML (@hdoc, '/AccountTypes/Id')
WITH(
    Id VARCHAR(10) 'Id'
    )

EXEC sys.sp_xml_removedocument @hdoc

No entanto, a saída disso é apenas linhas de nulos:

Id
NULL
NULL
NULL
NULL
NULL
NULL

em vez dos valores de id que eu esperava.

Obtenho os mesmos resultados independentemente de incluir o colpattern('Id') ou não ou se defino o flagsparâmetro no OPENXMLcomando.

Existe algo que eu possa fazer com os dados em sua forma atual para obter os valores reais do XML?

Eu tenho um procedimento armazenado do formulário:

CREATE PROCEDURE StoredProcedure
    @SearchString NVARCHAR(MAX),
    @ComparisonType INT
AS
BEGIN

    SELECT  A.Value1,
            B.Value1,
            C.Value1,
            ...
    FROM TableA as A
    INNER JOIN TableB as B on B.Key1 = A.Key1
    INNER JOIN TableC as C on C.Key2 = B.Key2
    WHERE A.DateValue > '2020-10-01'
    And 1 = CASE @SearchString
        WHEN N'' THEN 1
        ELSE
            CASE @ComparisonType
                WHEN 0 THEN -- potentially expensive query 1 referencing TableC
                WHEN 1 THEN -- potentially expensive query 2 referencing TableC
                WHEN 6 THEN -- potentially expensive query 3 referencing TableC
                WHEN 8 THEN -- potentially expensive query 4 referencing TableC
                WHEN 10 -- potentially expensive query 5 referencing TableC
                ELSE 0
            END
        END
END

Mesmo quando é chamado com @SearchStringdefinido para N''a consulta, leva um minuto e meio para ser executado. Se eu remover as partes da "consulta potencialmente cara", a consulta retornará os dados esperados praticamente instantaneamente.

Pelo que li, o acima não deve avaliar nada na ELSEparte da CASEdeclaração externa, @SearchStringentão N''por que ela age como se fosse?

Se isso estiver funcionando conforme o esperado, como codifico isso para forçar o SQL a não executar as partes de "consulta potencialmente cara"?

Estou tentando entender por que eles parecem afetar a consulta principal, apesar dos meus esforços para garantir que eles não sejam chamados.

Eu tenho um relatório com um parâmetro que geralmente obtém seus valores padrão executando uma consulta que recebe outro parâmetro como entrada. Isso funciona bem quando o relatório é executado interativamente.

No entanto, tenho um requisito para chamar este relatório do código onde todos os filtros são fornecidos pelo código. O código que tenho para os outros parâmetros funciona bem:

   string report = "Analysis/Report.aspx?ReportPath=/MyReport";
   string fullReportPath = string.Format("{0}&LocationId={1}&BatchNumber={2}&SearchReference={3}", report, locationId, batchNumber, reference);
   RunReport(fullReportPath);

Há uma lista suspensa onde os valores disponíveis e os valores padrão são recuperados do banco de dados por meio de uma consulta que tem locationIdcomo parâmetro. Isso é para que todos os valores sejam selecionados por padrão.

O que preciso mudar no relatório e/ou no código para que funcione como agora e eu possa fornecer os valores selecionados para esta lista suspensa como parâmetro?

Encontrei esta postagem de blog que usa o conceito de parâmetros de controle internos ou ocultos para usar ao definir os valores de outros parâmetros, mas o exemplo dado apenas define o outro parâmetro como um valor padrão ou o deixa em branco. Eu preciso que o parâmetro execute a consulta atual.

Estou usando o seguinte comando para gravar a saída de um procedimento armazenado em um arquivo para processamento adicional:

DECLARE @shellCommand VARCHAR(2000)
SET @shellCommand = 'SQLCMD -S ' + @@SERVERNAME + ' -d ' + @dbName + ' -U ' + @UserName + ' -P ' + @Password + ' -Q "' + @sqlCommand + '" -s "," -h -1 -k 1 -W -o "' + @outputfileName + '"'

@sqlCommandestá definido corretamente, como "EXEC StoredProcedureName parameterValue" e quando executado de forma independente aparentemente produz os dados corretos.

O problema que estou tendo é que um dos campos contém texto com mais de 256 caracteres e está sendo truncado quando alimentado por meio do comando SQLCMD.

Ao ler a documentação , vejo que a largura padrão da coluna é de 256 caracteres. Então, estou olhando para usar a opção -you -Ypara permitir que mais de 256 caracteres sejam gerados. No entanto, essas opções não são compatíveis com a -Wopção que eu estava usando para remover espaços à direita da saída. Comecei usando -y 0(apesar do aviso de desempenho - assim que a saída funcionar, posso observar o desempenho). No entanto, isso produz alguns resultados estranhos.

O arquivo consiste em uma linha de cabeçalho seguida pelas linhas de dados e deve se parecer com isto:

First,ABC,Number,String,ReallyLongString,...
A,0123,14.99,"Short string","Longish string",...
B,0456,23.99,"Normal string","Really, really long string that's causing problems",...

Com a -Wopção, o formato do arquivo está correto, mas a string realmente longa é truncada. A razão pela qual descobrimos foi porque o final "estava faltando e o arquivo não estava sendo lido corretamente.

Com -y 0a string realmente longa está obtendo saída, mas um grande número de espaços está sendo adicionado a colunas aparentemente aleatórias. Estamos recebendo algo assim:

First,ABC ,Number    [...]      ,String,ReallyLongString,...
A    ,0123,14.99     [...]      ,"Short string","Longish string",...
B    ,0456,23.99     [...]      ,"Normal string","Really, really long string that's causing problems",...

(Existem muitos, muitos mais espaços entre "Número" e a próxima coluna representada pelo "[...]", estou apenas mostrando alguns).

Existem mais valores numéricos que precisam ser formatados de maneira semelhante e parece que são esses que estão causando os espaços extras após o valor e antes da próxima vírgula. Podemos conviver com alguns espaços extras, mas não tantos, pois o arquivo resultante é muito grande para ser lido pelo programa de destino.

Os dados são gerados por um procedimento armazenado que se parece com isso:

SELECT
    'First' AS First,
    'ABC' AS ABC,
    'Number' AS Number,
    'String' AS String,
    'ReallyLongString' AS ReallyLongString,
    ...

UNION ALL

SELECT
    'A' as First,
    Column1 as ABC,
    REPLACE(FORMAT(Column2, 'N2', 'en-GB'), ',', '') as Number, -- to get the format correct
    '"' + Column3 + '"' as String,
    '"' + Column4 + '"' as ReallyLongString,
    ....
FROM Table
WHERE <condition>

Estou pensando que o problema é a saída do procedimento armazenado. Eu só adicionei a -Wopção ao SQLCMD por causa dos espaços extras à direita sendo gerados, mas olhando para o procedimento armazenado, não consigo descobrir de onde eles estão vindo. Alterei a formatação do número para incluir RTRIM:

RTRIM(REPLACE(FORMAT(Column2, 'N2', 'en-GB'), ',', ''))

mas isso parecia não fazer diferença.

Existe algo que eu possa fazer com o procedimento armazenado ou existe uma combinação de opções para SQLCMD que produzirá a saída desejada? Ou vou ter que encontrar alguma outra forma de produzir esse arquivo?

Eu tenho quatro tabelas - A, B, C e D.

A Tabela A contém registros de movimentação de estoque, a tabela B contém registros de vendas por item, a tabela C contém registros de não vendas por item e a tabela C contém o tipo de movimento de não venda.

Para cada registro em A, há uma linha em B ou uma linha em C. Portanto, para obter uma única linha dos movimentos de cada item, faço o seguinte:

select column1, column2, ... from A
left join B on B.Id = A.IdIntoB
left join C on C.Id = A.IdIntoC

Até agora tudo bem. Porém, como preciso saber que tipo de movimento foi em C como quero retornar o seguinte:

ItemId, Date, Sales, Goods In, Returns to Supplier

ou seja, ter colunas separadas para mercadoria recebida e devolvida a um fornecedor.

O tipo (bens recebidos ou devolvidos ao fornecedor) é armazenado em D e existe uma relação de muitos para um entre C e D, pois D é o "documento" que agrupa os itens em C.

Se eu fizer:

select column1, column2, ... from A
left join B on B.Id = A.IdIntoB
left join C as C1 on C1.Id = A.IdIntoC
    left join D on D.Id = C1.IdIntoD and D.Type = 1
left join C as C2 on C2.Id = A.IdIntoC
    left join D on D.Id = C2.IdIntoD and D.Type = 2

Acabei de obter linhas duplicadas, pois as duas junções de A a C são efetivamente as mesmas.

O que eu quero fazer é isso (sintaxe não legal):

select column1, column2, ... from A
left join B on B.Id = A.IdIntoB
left join C as C1 on C1.Id = A.IdIntoC and D.Type = 1
    left join D on D.Id = C1.IdIntoD
left join C as C2 on C2.Id = A.IdIntoC and D.Type = 2
    left join D on D.Id = C2.IdIntoD

Basicamente, quero separar as junções entre A e C com base em um valor em D. Sei que tenho que usar a left joinentre C e D todas as vezes, caso contrário, não obterei dados, mas logicamente é isso que sinto que preciso fazer .

Como eu faço isso?

Eu preciso adicionar a parte da data à parte do GetDate()tempo de um arquivo DateTime.

Ingenuamente, pensei que poderia fazer o seguinte:

declare @testTime DateTime = '2013-04-23 13:55:06'
select cast(getdate() as date) + cast(@testTime as time)

mas esta dando o seguinte erro:

A data do tipo de dados do operando é inválida para o operador de adição.

Eu fiz mais algumas pesquisas e descobri três maneiras possíveis de fazer o cálculo:

declare @testTime DateTime = '2013-04-23 13:55:06'

select dateadd(dd, 0, DATEDIFF(dd, 0, GetDate())) + cast(@testTime as time)

select cast(cast(GetDate() as date) as datetime) + cast(@testTime as time)

select dateadd(day, datediff(day, @testTime, GetDate()), @testTime)

Todos os três produzem o mesmo resultado, mas não estou 100% satisfeito com a implementação de nenhum deles, embora a terceira maneira pareça ser uma maneira melhor - embora não tenha evidências disso.

Qual (se houver) dos três é o mais eficiente?

Existe uma maneira melhor?