A veces, las columnas calculadas que faltan en SELECT *

En SQL Azure, tengo una tabla más o less configurada de esta manera, con dos columnas calculadas ( IsExpinetworking e IsDeadlineExpinetworking ) que simplemente comparan las columnas datetime que no IsExpinetworking IsDeadlineExpinetworking con la hora actual:

 CREATE TABLE [dbo].[Stuff] ( [StuffId] int NOT NULL IDENTITY(1,1), [Guid] uniqueidentifier NOT NULL, [ExpirationDate] datetime NOT NULL, [DeadlineDate] datetime NOT NULL, [UserId] int NOT NULL, [IsExpinetworking] AS CAST((CASE WHEN [ExpirationDate] < GETUTCDATE() THEN 1 ELSE 0 END) AS bit), [IsDeadlineExpinetworking] AS CAST((CASE WHEN [DeadlineDate] < GETUTCDATE() THEN 1 ELSE 0 END) AS bit), CONSTRAINT [PK_StuffId] PRIMARY KEY ([StuffId]), CONSTRAINT [UNQ_Guid] UNIQUE([Guid]), ) GO 

Tengo un procedimiento almacenado con varios sets de resultados, uno de los cuales extrae:

 SELECT * FROM [dbo].[Stuff] WHERE [Guid] = @guid 

Recientemente noté loggings de errores que indican que, en ocasiones, cuando se lee el set de resultados con SqlDataReader , SqlDataReader.GetOrdinal("IsExpinetworking") falla con IndexOutOfRangeException . Sé que las columnas anteriores funcionan bien incluso en esos casos, ya que se leen en líneas de código anteriores sin errores. También creo que los sets de resultados del procedimiento están en la secuencia correcta, ya que no comparten los nombres de las columnas (de lo contrario, la lectura de las columnas anteriores también fallaría).

Además: la mayoría de las veces todo parece funcionar perfectamente.

¿Puede esto atribuirse de alguna manera a las fallas transitorias de Azure?

Por favor, consulte este artículo: SELECCIONE * Y SQL Azure .

Su autor recomienda encarecidamente replace

 SELECT * FROM TableName 

con

 SELECT [Column1], [Column2], ... [ColumnN] FROM TableName 

porque usar SELECT * puede causar pagination adicional, búsquedas de RFID, locking innecesario de la tabla y obstaculiza cualquier bash futuro de crear un índice cubierto. En resumen, es malo para el performance .

By The Way: aquí tienes un set de artículos interesantes:

  1. Cómo llegar a SQL Azure Query Performance Data
  2. Rendimiento de consulta
  3. Comenzar con las herramientas de Windows Azure para Visual Studio
  4. Comenzar con el desarrollo de SQL Azure
  5. Mejorando su performance de E / S
  6. Analizar el performance de las consultas ahora es más fácil con SQL Azure.

Sospecho que GetOrdinary ("IsExpinetworking") causa System.IndexOutOfRangeException debido al comportamiento anterior del marco MS SQL Azure.

¿Conclusión? Utilice la instrucción SELECT con la list de columnas definida para mejorar el performance de la database SQL Azure y evitar la exception IndexOutOfRange.

Mirando algunos loggings antiguos, llegó a la conclusión de que este error solo ocurría cuando las consultas se estaban ejecutando mientras se estaba implementando simultáneamente un DACPAC (como parte de nuestras implementaciones automatizadas para este entorno de testing en particular).

Supongo que el esquema no está necesariamente en un estado confiable durante la implementación de DACPAC.

Desde entonces, hemos agregado un código para poner la aplicación en un "modo de mantenimiento" durante las implementaciones (incluso estas automatizadas). Esto parece mitigar el problema.