David Clarke's questions

Eu sei que há uma resposta simples para esta pergunta, mas simplesmente não consigo entender. Eu tenho uma tabela com colunas datetime e int.

| TimeStartTz             | RowNumber | RateID      |
|-------------------------|-----------|-------------|
| 2018-05-07 07:00:00.000 | 45        | 1           |
| 2018-04-09 07:00:00.000 | 43        | 1           |
| 2018-03-26 07:00:00.000 | 42        | 1           |
| 2018-03-19 07:00:00.000 | 41        | 1           | <-- want this row
| 2018-03-05 07:00:00.000 | 2         | 2           |
| 2018-02-26 07:00:00.000 | 1         | 2           |
| 2018-02-19 07:00:00.000 | 40        | 1           |
| 2018-02-12 07:00:00.000 | 39        | 1           |
| 2018-01-29 06:45:00.000 | 38        | 1           |
| 2018-01-22 06:45:00.000 | 37        | 1           |

Eu quero pegar a linha da mudança mais recente no RateID ou a primeira linha se não houver nenhuma mudança no conjunto, ou seja, no exemplo a linha com RowNumber41. Tentei particionar por RateID mas obviamente não leva em conta seções contíguas :

    ROW_NUMBER() OVER (PARTITION BY pq.[RateID] ORDER BY pq.[TimeStart]) RowNumber

Estou atualizando uma tabela de auditoria/log que é preenchida pelo gatilho quando uma tabela é atualizada. Minha intenção é usar as sys.objects.object_idcolunas for table name e column name na tabela de log, mas não é possível usar uma referência FK para as visualizações do sistema. Existe alguma alternativa útil para manter a integridade referencial na tabela?

Eu tenho um banco de dados no qual várias tabelas são definidas com várias colunas UUID formando a chave primária quando elas devem ser definidas como chaves estrangeiras, por exemplo

CREATE TABLE [dbo].[SomeTable](
    [SomeTableID] [uniqueidentifier] NOT NULL,
    [WorkEntryID] [uniqueidentifier] NOT NULL,
    [TimeEntryID] [uniqueidentifier] NOT NULL,
    [RateEntryID] [uniqueidentifier] NOT NULL,
    ...

 CONSTRAINT [PK_SomeTable] PRIMARY KEY CLUSTERED 
 (
    [SomeTableID] ASC,
    [WorkEntryID] ASC,
    [TimeEntryID] ASC,
    [RateEntryID] ASC
 )
) ON [PRIMARY]
GO

ALTER TABLE [dbo].[SomeTable] ADD  CONSTRAINT [DF_SomeTable_SomeTableID]  DEFAULT (newsequentialid()) FOR [SomeTableID]
GO

As colunas adicionais deveriam ter sido definidas como Chaves Estrangeiras e em alguns casos foram. Estou assumindo que há implicações de desempenho de ter as colunas adicionais como parte do PK? Há alguma consideração que eu deva estar ciente antes de redefinir o PK para que as tabelas incluam apenas a coluna PK?

Eu apoio um aplicativo que usa modelos CodeSmith e NetTiers para gerar código C#. CodeSmith inspeciona o banco de dados e usa a SET FMTONLY ONconfiguração para determinar as colunas para as quais o código deve ser gerado.

Infelizmente, ao mudar do SQL Server 2005 para 2012, há uma circunstância específica em que isso não está mais funcionando. Existe um procedimento armazenado que executa um procedimento armazenado em um servidor vinculado e o código que está sendo gerado para esse procedimento armazenado está incorreto.

Consegui isolar o problema da EXECdeclaração com SET FMTONLY ON. O seguinte (somente exemplo) SELECTfunciona nas instâncias de 2005 e 2012:

SET FMTONLY ON
SELECT TOP(10) [MCMCU]
              ,[MCSTYL]
              ,[MCDC]
FROM [JDE].[JDE_CRP].[CRPDTA].[F0006]
SET FMTONLY OFF

Isso retorna apenas os títulos das colunas, conforme esperado. O seguinte funciona apenas na instância de 2005:

SET FMTONLY ON
EXEC('SELECT TOP(10) [MCMCU]
                    ,[MCSTYL]
                    ,[MCDC]
      FROM [JDE_CRP].[CRPDTA].[F0006]') AT [JDE]
SET FMTONLY OFF

Quando executado na instância 2012, o SSMS mostra a mensagem "Comando(s) concluído(s) com êxito", mas não exibe os cabeçalhos das colunas.

Há alguma coisa que estou perdendo aqui? Talvez uma configuração que eu precise alterar? As definições do servidor vinculado são idênticas, incluindo a identidade usada para conectar. E sim, estou ciente de que FMTONLYestá obsoleto, mas não tenho nenhuma capacidade de alterar a maneira como o CodeSmith interroga o banco de dados.

Não tenho certeza de como formular essa pergunta. Eu tenho uma tabela que possui várias colunas, incluindo uma coluna id, uma coluna de chave estrangeira 'JobId' e uma coluna 'GxpId'.

Eu tenho um requisito de que um 'JobId' pode ter no máximo um 'GxpId', mas a tabela pode ter várias linhas com o mesmo 'JobId' e 'GxpId'.

Há um processo separado que está importando dados para a tabela e o aplicativo que usa a tabela falhou porque o processo de importação criou duas linhas com o mesmo 'JobId', mas 'GxpId' diferente.

Gostaria de adicionar uma restrição à tabela para garantir que qualquer linha para um 'JobId' específico tenha o mesmo 'GxpId'. Espero que isso faça sentido.

Eu tenho uma coluna RSEFlag que contém um valor de sinalizador que é a soma de um ou mais de 1, 2, 4. Tenho uma tabela separada que contém a descrição de cada um desses valores de sinalizador:

RSECode RSEDescription
------- --------------
   4    Environment
   1    Reliability
   2    Safety

Gostaria de restringir minha coluna RSEFlag para que seja menor ou igual à soma dos valores da tabela RSE.

Este é um exercício que vale a pena e qual é a melhor abordagem?

Eu tenho uma tabela com aproximadamente 3.000 linhas e preciso modificar uma definição de coluna para permitir nulos. Eu tenho um script de alteração que fará a alteração, mas gostaria de poder executar novamente o script para que a alteração ocorra apenas se a definição da coluna ainda não tiver sido alterada. Como faço para testar uma definição de coluna para identificar se a coluna é NULL ou NOT NULL?

Eu tenho uma tabela (SQL Server) que contém 3 tipos de resultados: FLOAT, NVARCHAR(30) ou DATETIME (3 colunas separadas). Quero garantir que, para qualquer linha, apenas uma coluna tenha um resultado e as outras colunas sejam NULL. Qual é a restrição de verificação mais simples para conseguir isso?

O contexto para isso é tentar adaptar a capacidade de capturar resultados não numéricos em um sistema existente. Adicionar duas novas colunas à tabela com uma restrição para evitar mais de um resultado por linha foi a abordagem mais econômica, não necessariamente a correta.

Atualização: Desculpe, tipo de dados snafu. Infelizmente eu não pretendia que os tipos de resultados indicados fossem interpretados como tipos de dados do SQL Server, apenas termos genéricos, corrigidos agora.