Pues a Microsoft parece ser que no, tal como responde en la propuesta de connect.com “new virtual table: errors. It would analogous to the deleted and inserted tables” (la negrita es cosecha propia):
“[…] After carefully evaluating all of the bugs in our pipeline, we are closing bugs that we will not fix in the current or future versions of SQL Server. The reasons for closing this bug is because the scenario reported in the bug are not common enough […]”
Es decir, que el hecho de poder saber cuál(es) es(son) la(s) razón(es) por la(s) que, por ejemplo, un INSERT…SELECT ha fallado y poder decidir si rechazar la operación al completo (tal como sucede ahora, pero además sin conocer todos los posibles problemas) o aceptarla sabiendo que ciertas filas no han podido ser insertadas, no parece una mejora susceptible de ser incorporada (a pesar de que la competencia ya la tiene, como se explica en “Faster Batch Processing”) Porque claro, ¿quién usa un INSERT…SELECT hoy en día?
Tampoco es suficientemente común la creación de procesos ETL donde se cargan los datos en un Datawarehouse y es necesario identificar qué filas han fallado para moverlas a una tabla de errores. Y es que, ¿quién tiene un Datawarehouse en su empresa?
Por supuesto, nadie ha hecho una transferencia masiva de datos de un origen a otro (¿migraciones acaso?) y las ha pasado canutas hasta identificar el valor de la columna que hacía que todo el proceso se cancelara casi justo al final… Claro, es que son escenarios excepcionales.
Si te has recordado en alguna de estas situaciones, no dudes en votar a favor de que Microsoft reconsidere la incorporación de esta funcionalidad, porque podrá ser cualquier cosa, pero “poco común” desde luego que no.
