Tài liệu Visual Studio 2005 y SQL Server 2005 doc

El real valor de las certificaciones del mundo informático (de sus realidades, mitos y proyección)
opinión
nº3 abril 2004 • Precio: 6,00 € (España)
Visual Studio 2005 y SQL Server 2005
Whidbey y Yukon ya tienen nombre
El poder de la reflexión en .NET
Generación de tipos en tiempo de ejecución
Visual Studio 2005 y SQL Server 2005
Whidbey y Yukon ya tienen nombre
El poder de la reflexión en .NET
Generación de tipos en tiempo de ejecución
Laboratorio
Crystal Enterprise v10
Open Source
datNet
Comunidades
Concurso de creación de páginas Web
con ASP.NET
Laboratorio
Crystal Enterprise v10
Open Source
datNet
Comunidades
Concurso de creación de páginas Web
con ASP.NET
Equivalencia de instrucciones
de C# y VB .NET (y III) •
Configuración de
aplicaciones Web de ASP.NET
• Gestión de concurrencia en
ADO.NET • Introducción a

GDI+ • SQL-Server. Diseñar la
estrategia de copias de
seguridad y restauraciones •
El Señor Arquitecto
Equivalencia de instrucciones
de C# y VB .NET (y III) •
Configuración de
aplicaciones Web de ASP.NET
• Gestión de concurrencia en
ADO.NET • Introducción a
GDI+ • SQL-Server. Diseñar la
estrategia de copias de
seguridad y restauraciones •
El Señor Arquitecto
dotNetManía
dotNetManía
www.dotnetmania.com Dedicada a los profesionales de la plataforma .NET
Visual Basic.NET • C# • Delphi • ASP.NET • ADO.NET • .NET Framework • Windows Server System
Por supuesto, la noticia del mes es el retraso que
sufrirán los lanzamientos de Whidbey y Yukon que
se trasladan a mediados del 2005 y que saldrán al
mercado conjuntamente bajo los nombres Visual
Studio 2005 y SQL Server 2005. Algunos usuarios
han mostrado su malestar al respecto, puesto que
habían pagado por el programa Software Assurance
durante tres años sin recibir ninguna actualización
principal a cambio. Luego están los que se preocu-
pan por el soporte de las versiones actuales que pue-
den terminar de ofrecerse con poca diferencia con

las versiones nuevas. Otros opinan que lo mejor es
que el software salga al mercado cuando realmente
esté listo y que esto es mejor aunque haya que espe-
rar algo más. Pero es que todo esto afecta a tantas
cosas que sería mejor que estos chicos de Microsoft
afinasen más, si bien es cierto, que yo me encuentro
entre los que opinan que los lanzamientos precipi-
tados para cumplir fechas son a la larga peores para
los usuarios.
Acabamos de recibir la noticia de la multa de
casi 500 millones de euros (la más alta impuesta
hasta ahora por este organismo) que la Comisión
Europea ha impuesto a Microsoft por supuesto
abuso de posición dominante en el mercado euro-
peo. Ahora se iniciará una nueva, larga y aburrida
batalla legal, por supuesto. Esto viene después de
que Steve Ballmer hiciera un viaje inesperado a
Bruselas, cancelando su keynote en el Summit el
miércoles 17, en la que se especulaba que habría
una demo de Indy, para intentar llegar a una sali-
da negociada que finalmente no fue posible.
¿Tendremos un Windows europeo distinto del res-
to? ¿Esta Comisión no debería ser más dura con
otros monopolios de hecho que sufrimos los usua-
rios de manera sangrante? ¿Lo han hecho en bene-
ficio de los usuarios o de los competidores de
Microsoft? Me consta que los fabricantes de Real
Player, Real Networks están muy satisfechos.
Personalmente a mí me importa poco si Windows
lleva o no Windows Media Player, de todas formas

yo uso Winamp, pero un sistema operativo debe
ser capaz de abrir el máximo tipo de archivos posi-
ble. ¿Harán lo mismo con los visualizadores de
otros tipos de archivos? ¿Es mejor para los usua-
rios un sistema operativo incapaz de abrir archi-
vos en aras a que la competencia pueda vender sus
visores?
No quisiera terminar sin tener un sentido
recuerdo para las víctimas y sus familiares y ami-
gos del atentado cometido por seres humanos en
Madrid el 11 de marzo. Extraña palabra la palabra
“humanidad” que suele usarse como aglutinadora
de todos los buenos sentimientos que sólo los
humanos podemos sentir. Me pregunto si también
debería servir para aglutinar todo lo malo que sólo
los humanos podemos hacer. Sólo un humano pue-
de ser tan despiadado. ¿Fue, pues, éste un acto de
“humanidad”? Cómo me avergüenza pertenecer a
la misma especie animal que alguno de mis con-
géneres. No debemos olvidar tampoco a los muer-
tos en Nueva York, en Irak, en Afganistán, en Pales-
tina, en Israel, y en tantos sitios donde mueren ino-
centes y no tan inocentes a manos de asesinos lega-
les o ilegales ¿en nombre de quién? Desde luego
no en mi nombre.
dotNetManía
<<
3
No en mi nombre
<<

dnm.editorial
<<
dnm.editorial
Editor
Paco Marín
()
Administración
Pilar Pérez
()
Asesor Técnico/Coordinación
Marino Posadas
()
Publicidad
Juan Manuel Urraca
()
Redactores y Colaboradores
Alejandro Mezcua, Angel Esteban,
Antonio Quirós, Antonio Rojo, David
Carmona, Eladio Rincón, Francisco
Charte, Fernando Guerrero, Fernando
Nogueras, Guillermo ‘guille’ Som, Iván
González, Jesús López, Jordi Rambla,
Jorge Serrano, José Manuel Alarcón, Juan
Torres, Liborio López, Luis Miguel Blan-
co, Marino Posadas, Miguel Egea, Miguel
Katrib, Pablo Abbate, Pedro Gómez,
Pedro Pozo, Pepe Hevia, Salvador Ramos
Diseño y Maquetación
Éride Diseño Gráfico
Tel.: (34) 91 477 48 85

• www.eride.net
Edita
Netalia
c/ Robledal, 135
28529 Rivas-Vaciamadrid (Madrid)
Tf. (34) 91 6667477
Fax (34) 91 4991364
Imprime
Gráficas Vallehermoso
www.graficasvallehermoso.com
Depósito Legal
M-3.075-2004
Suscripciones

Redaccion

Nuevos colaboradores

3
dnm.sumario
El real valor de las certificaciones del mundo informático 8-10
(de sus realidades, mitos y proyección)
El mundo de las certificaciones IT, casi desde su aparición ha generado
controversia, entusiastas y detractores.
Equivalencia de instrucciones de C# y VB .NET (y III) 11-14
Cómo hacer las mismas cosas (o casi) en C# y Visual Basic .NET
Tercera y última entrega de esta serie de artículos en la que hemos pretendido explicarle
cómo hacer las mismas cosas (o casi) tanto en C# como en Visual Basic .NET
Configuración de aplicaciones Web de ASP.NET 16-19
En versiones anteriores de la tecnología ASP, la configuración de aplicaciones Web

se realizaba de forma muy distinta. En este artículo damos un breve repaso a las
opciones principales de configuración de ASP.NET
Gestión de concurrencia en ADO.NET 20-26
La concurrencia, en un entorno multiusuario, es siempre una cuestión
problemática, pero si además se trata de un entorno desconectado como el que se
usa en ADO.NET con sus DataSets y DataAdapters, la problemática es aún
mayor debido a la propia naturaleza desconectada del entorno.
El poder de la reflexión en .Net 27-34
Este trabajo muestra cómo usando reflection se define un conversor de tipos que
permite a partir de un objeto, el cual comparte una misma funcionalidad con un
interface, obtener un objeto proxy equivalente en funcionalidad al original pero
que garantiza ser subtipo de dicha interface.
Introducción a GDI+ 37-42
La llegada de la tecnología .NET ha venido acompañada de GDI+ (Graphics
Device Interface), que como su nombre deja entrever, se trata de la nueva
generación del API gráfico de Windows, adaptado a la plataforma .NET
Framework.
SQL-Server. Diseñar la estrategia de copias de seguridad y restauraciones 43-49
Todos los sistemas necesitan una salvaguarda, pero aquellos que contienen datos
importantes mucho más aún. En una base de datos suele guardarse información
muy viva y casi siempre trascendental para el negocio que sustentan.
El Señor Arquitecto 50-51
Parece que la arquitectura está de moda. ¿A qué se debe toda esa artillería?
¿Hemos de escondernos en la trinchera hasta que pase la tormenta, o ese bombardeo
sirve para allanar el camino hacia el combate con nuestro enemigo virtual?
Crystal Enterprise v10 52-53
Business Objects, líder en el área de Business Intelligence, acaba de lanzar las primeras
versiones bajo su égida de los productos Crystal, adquiridos a Crystal Decisions. En este
artículo presentamos Crystal Enterprise 10 [CE10], el hermano mayor de una familia
que también incluye a Crystal Analysis y al ampliamente conocido Crystal Reports.

Biblioteca 54
C# al descubierto de Joseph Mayo.
Arquitectura de aplicaciones para .NET. Diseño de apicaciones y servicios de
Microsoft Press.
Comunidades 55
Concurso de creación de páginas Web con ASP.NET para la comunidad de
desarrolladores de ASP.NET en España
Open Source 56-57
dataNet
Desván 58
dnm.sumario
E
n
tre
g
a
e
s
t
e
c
u
p
ó
n
y
o
b
te
n

d
r
á
s
5
0
7
d
e

d
e
s
c
u
e
n
to
a
l
in
s
c
ri
b
ir
te
a
n
u

e
s
t
ro
s
p
ro
g
r
a
m
a
s
dotNetManía
<<
6
dnm.noticias
<<
dnm.noticias
Whidbey y Yukon
ya tienen nombre: Visual Studio 2005
y SQL Server 2005
En el número anterior de dotNetManía ya ade-
lantábamos como rumor el retraso que sufriría
Whidbey, según palabras del “padre” de ASP.NET
2.0, Scott Guthrie. Pues bien, ya no es un rumor.
El día 10 de marzo, Microsoft hizo público el retra-
so que sufrirán tanto Whidbey como Yukon, que
pasan de estar listos antes de terminar el 2004 a
estarlo en el primer semestre de 2005. Fue el

momento para asignarles su nombre comercial:
Visual Studio 2005 y SQL Server 2005.
Según fuentes de Microsoft, “Microsoft ha
tomado la decisión de retrasar la entrega de estos
productos para poder llegar a ofrecer los altísi-
mos requerimientos que nos han pedido nuestros
clientes”.
Según Tom Rizzo, Director of Product
Management for SQL Server, hemos decidido sacar
una beta 2 de Yukon y una beta 1 de Whidbey hacia
mediados de 2004 y finalmente una beta 3 de
Yukon para finales de 2004 que no estaba previs-
ta. Ambos productos van a estar estrechamente
integrados, se lanzaron a la vez.
El soporte completo de SQL Server 7 y SQL
Server 2000 termina en el año 2005, por lo que el
retraso en la salida de la nueva versión de SQL
Server, significa que habrá menos tiempo para la
migración. ¿Supone este retraso en la salida de
Yukon, un retraso igual en la fecha tope de sopor-
te de las versiones anteriores? Según el citado Tom
Rizzo, Microsoft está considerando una amplia-
ción de este soporte.
Además, esto puede tener, a nuestro juicio, un
claro efecto dominó. Longhorn, la siguiente ver-
sión de Windows, sufrirá posiblemente un retra-
so en su salida, al igual que puede ocurrir con el
Office 12, la versión de Office para este sistema
operativo. Hay que tener en cuenta que este sis-
tema operativo usará a Yukon para gestionar los

datos del sistema. Así mismo, las nuevas versiones
de productos como SharePoint Portal Server,
Content Management, Commerce Server depen-
den estrechamente de ASP.NET 2.0 e igualmen-
te se pueden ver afectados.
Claro que hay fuentes que aseguran que el
retraso es precisamente porque una buena parte
de los desarrolladores de Yukon están trabajando
en WinFS, y no sería de extrañar pues la salida de
Longhorn es vital para la compañía y empieza a
especularse que podría irse hasta el 2007.
Oficialmente, Microsoft sólo reconoce el posi-
ble retraso de Orcas que estaría disponible un par
de años después de la salida de Whidbey, según
afirma Ari Bixhorn, Visual Studio Lead Product
Manager, en una entrevista concedida a eWeek.
noticias.noticias.noticias.noticias.noticias.noticias
dnm.noticias
<<
Nuevas versiones de Windows
Windows 2003 R2 para 2005
Microsoft ha confirmado su intención de lanzar Windows 2003
R2, una actualización que evolucionará al actual Windows 2003
Server antes de la salida de Longhorn. Se rumorea que posible-
mente aparezca en el verano de 2005.
Estará diseñado para combinar las características de la versión
gold de Windows 2003, Windows 2003 SP1 y los llamados “fea-
ture packs” o actualizaciones que se han ido sirviendo desde su apa-
rición. Aún no tenemos noticias sobre su comercialización, aun-
que esperamos sea una actualización gratuita para los clientes actua-

les de Windows 2003.
El SP1 de Windows 2003 quizá esté disponible para finales de este año.
Una de las posibles mejoras que la nueva versión tenga sea soporte para Indigo así como otras carac-
terísticas del lado del servidor de Longhorn, aún por determinar, e incluirá la nueva versión del .NET
Framework que saldrá el año que viene.
Esto es completamente lógico pues la nueva versión del sistema operativo del servidor aparecerá des-
pués de Longhorn y el actual Windows 2003 tendrá que soportar a los PCs que se conecten con Longhorn
instalado.
Puede obtener más información en la Web de Paul Thurrott’s en http://www
.winsupersite.com.
Windows XP SP2 para 2004
Windows XP SP2 es una actualiza-
ción de Windows XP que incluye mejo-
ras de seguridad como el nuevo
Windows Security Center que centrali-
zará la configuración de seguridad y que
incluye incluso protección antivirus; un
nuevo firewall que reemplaza al actual
ICF (Internet Connection Firewall) con
políticas de grupo integradas en el
Active Directory; una nueva versión de
RPC para protección contra ataques en
la red;un bloqueador de popups y un
gestor de descargas en el también nuevo Internet Explorer junto con mejoras de seguridad en el
Outlook Express y en el Windows Messenger; un nuevo Windows Update; una remodelada protec-
ción de memoria para evitar los comunes “overruns”; mejoras de seguridad en el Windows Media
Player; y otros cambios.
La RC1(Release Candidate 1) de Windows XP SP2 ya está disponible y los betatesters registrados
pueden descargarla desde Puede obtener más información
en el MSDN en />rityinxpsp2.asp

dnm.noticias
dotNetManía
<<
8
De sus realidades y de sus mitos
Cuando estaba en la universidad, una de las cosas
que siempre tuve muy claras era la del hecho de bus-
car una certificación IT avalada. Cuando rendí mi pri-
mer examen, hace ya varias líneas de código = ), la ver-
dad estaba demasiado nervioso. Como cualquier neó-
fito, compartí mi tensión , con mis parceros (amigos)
y mi familia, hablándoles de lo que para mí en ese
entonces implicaba un espléndido reto. Al final del
examen todo salió bien (es un momento que aún
recuerdo con sonrisa en el rostro), llamé a mi familia
y le escribí a mis amigos del suceso… Varios de uste-
des se preguntarán porqué esta introducción de índo-
le tan personal; pues bien así de importante fue para
mi rendir mi primer examen de certificación, pero con
el correr de los días dicha ilusión fue al traste…
" Las certificaciones IT, desafortunadamente, no
son tan importantes como crees, es más, fue un dife-
renciador algún tiempo, pero con los días se ha con-
vertido en toda una farsa.", me repitió mi maestra de
construcción de software. Lo curioso es que para esos
días en Colombia (hace siete años aproximadamente),
la cantidad de certificados era mucho menor, e inclu-
so, ella viajó a Estados Unidos para tomar la capacita-
ción debida, pues no existía en el país ese tipo de entre-
namiento aun. Le pregunté por qué razón afirmaba tal

cuestión, " Willy, verás en estas URL's los exáme-
nes están a la venta…", la verdad no podía creerlo, no
podía creer que después de invertir cerca de 500 dóla-
res en una semana de educación técnica (demasiado
dinero para las economías "latam" en esos días e inclu-
so hoy) y pagar 80 dólares aproximadamente por el
examen, alguien vendiera la prueba por 200 dólares
aproximadamente (mucho más que para esos días el
salario promedio para un desarrollador no sumaba más
de 220 dólares mensuales en el mejor de los casos a
este lado del charco), quedé realmente desilusionado,
y entendí que nunca las certificaciones equivaldrían o
superarían las ingenierías por dos razones: una de ellas,
la que acabo de relatar; y la siguiente, porque las tec-
nologías tienen una duración muy corta, en cambio,
cuando eres ingeniero, tus bases "ingeniériles" duran
para siempre (aunque la verdad es que hoy me lleva-
ría un rato recordar la metódica de solución a las trans-
formadas de fourier =P).
Con ello y otros bemoles, seguí igual tomando mis
cursos técnicos y rindiendo mis exámenes (incluso per-
dí el 70-300, un examen de arquitectura de .NET en
el primer intento, hace sólo algunos meses). A estas
alturas usted se puede preguntar ¿porqué seguir rin-
diendo estas pruebas, que pareciere que día a día, estu-
vieren más y más a la venta por unos pocos dólares?
(La verdad es que me asombra el nivel de fidelidad de
esos documentos; es tal el descaro, que salen hasta las
capturas de pantalla). ¿Porqué rendir una prueba que
tiene un coste tan alto, si las respuestas están a la ven-

ta por un valor con el cual podría comprar el examen
El real valor de las certificaciones
del mundo informático (de sus realidades,
mitos y proyección)
Por Willy Marroquín
Visual Basic MVP
willydev.net
<<
El mundo de las certificaciones IT, casi desde su aparición ha generado controversia, entu-
siastas y detractores. En este escrito,daré una percepción personal a lo que pueda referir de
este tema, así que ¡allí vamos!
completo? -Cuando hago referencias a ellos, no me
refiero a las pruebas de preparación o a los libros que
se escriben sobre tema, desde luego Ojalá las multi-
nacionales IT que tienen que ver con estos procesos de
certificación, acaben con este cuento pronto; realmen-
te es lamentable que ello suceda y no se pronuncien.
Todas las compañías después de aprobar algunos de
sus exámenes, hacen llegar una especie de certificado
impreso y alguna documentación, pero siendo objeti-
vos, no pasa de allí la cuestión, la verdad es que me pare-
ce un poco desigual el "trato". El porqué de este comen-
tario viene a lo siguiente: si una compañía IT promue-
ve como un alto grado de avance el hecho de certifi-
carse, lo mínimo que esperaría sería la generación de
bolsas de empleo de las personas que certifican o la pro-
moción de dichas personas por algún tipo de canal, cosa
que ha día de hoy no sucede y parece que se divise (este
último comentario es una generalidad, desde luego, por
estos lados, las personas de Microsoft, están retoman-

do el tema con toda la fuerza que amerita).
Una perspectiva mundial
y los certificados
Recientemente una de las publicaciones más
importantes en el tema, MCPMag.com, publicó el
resultado de su estudio de salarios con respecto a los
profesionales certificados (no sólo de Microsoft, sino
de diferentes compañías), disponibles en http://mcp-
mag.com/salary2003/ (les recomiendo mucho la lec-
tura de este documento). Muestra dos tendencias cla-
ras: el nivel de profesionales ha aumentado conside-
rablemente, a medida que las certificaciones técnicas
han pasado a ser necesidad por solicitud de los emple-
adores y una tendencia al aumento de sus salarios…
entonces ¿qué es lo inclusive de esta encuesta? Bueno,
dicha labor de recolección de información, sólo se lle-
vó acabo en Estados Unidos, ¿y el resto de nosotros
donde quedamos? ¿Será que nuestras economías pue-
den equipararse en proporción a salarios…? La res-
puesta evidentemente es no. Lo que implicaría que el
coste de dicho tipo de educación fuere proporcional-
mente ajustada. No son lo mismo 100 dólares en
Estados Unidos que en Latam
dotNetManía
<<
9
dnm.opinion
<<
Figura 1. Reporte de Certificados a Febrero
de 2004

Figura 2. Reporte de MCP's en los últimos nueve meses
Figura 3. Reporte de MCSD's en los últimos nueve meses
Figura 4. Reporte de MCT's en los últimos nueve meses
Desde luego las variables macroeco-
nomías influyen localmente, pero si se ve
con detenimiento el coste de este tipo de
formación IT, no sólo debería ser ajus-
tada localmente, sino después de ajusta-
da, reducirse por lo menos a la mitad. La
justificación de esta premisa está en que
somos nosotros los IT (me refiero a todo
el gremio, pero con más fuerza a los desa-
rrolladores de software) quienes hace-
mos que las plataformas permanezcan
y/o se difundan, ello debido a nuestra
inclinación hacia la misma (llámese como
se llame), pues si no hay productos para
la plataforma X o Y, ésta pierde su posi-
cionamiento pero bueno ello daría para
otro escrito de esta saga.
Debido al crecimiento de las certi-
ficaciones como requisito, se hace cada
vez más importante la intervención de
la industria, para que estas credenciales
conserven (o en algunos casos recupe-
ren) su buen nombre.
Una buena alternativa, pudiere ser el
hecho de exigir un tiempo comprobable
con la tecnología antes de rendir la prue-
ba de certificación de la misma y con ello

sustentar la credencial en caso de rendir
positivamente la prueba. A día de hoy,
algunas compañías, mantienen esta mecá-
nica. Esto permite mantener la credibi-
lidad en la credencial y en consecuencia
del profesional que decide tomarlas y me
lleva al siguiente punto de este escrito
¿Contrataría usted a un
profesional sin experiencia
de campo y con certificaciones
a su haber?
Esta es la misma pregunta que debe-
rían hacerse las personas que se logran
certificar de una manera, cómo decir-
lo… "poco ortodoxa".
Si me hicieran esta pregunta, mi res-
puesta sería un contundente JAMÁS (¿de
qué me sirve un experto de diploma, si
en realidad tengo un fiasco como emple-
ado?). Desde mi perspectiva, es sencilla-
mente inconcebible que un profesional
diga tener credenciales que lo habilitan
como experto en un frente tecnológico
y que no posea experiencia. Si usted es
empleador, es muy buena idea enterarse
del Skill de cada certificación, y con ello
determinar si es equiparable lo uno con
lo otro. Es notorio que la certificación es
un diferenciador, pero no lo será por
mucho tiempo, pasará a ser un requisito

(así se puede leer en la encuesta de
MCPMag que recomendaba unas líneas
arriba), aunque bueno fuera que reco-
brara su estatus de credibilidad.
A pesar de esta posición un poco
escéptica (y desde luego desde una pers-
pectiva muy personal y ya para rematar
estas líneas), usted debe tener en cuen-
ta que las certificaciones son buena idea,
pero aún mejor idea es conocer a fon-
do las tecnologías para ser un real exper-
to… así no te certifiques. Nos vemos en
un próximo articulo… debo seguir estu-
diando para rendir mi próxima certifi-
cación =).
dotNetManía
<<
10
dnm.opinion
<<
noticias.noticias.noticias.noticias
Con motivo del Silicon Valley Speaker Series,
en marzo de 2004, Microsoft presentó
BizTalk® Server 2004. BizTalk es una solu-
ción de integración líder en la industria y
miembro del Windows Server System™. Las
aplicaciones creadas con BizTalk Server 2004
corren bajo .NET Framework, lo cual per-
mite a los clientes automatizar y administrar
procesos empresariales complejos al integrar

aplicaciones, socios comerciales y emplea-
dos con el núcleo de organización de proce-
sos altamente escalable de BizTalk Server.
BizTalk Server 2004 ayuda a incrementar la
productividad de los trabajadores con infor-
mación, los profesionales en TI y los desa-
rrolladores a través de herramientas especí-
ficas para desarrollar, administrar y acceder
a los procesos empresariales en entornos
familiares tales como Microsoft Office
System y Visual Studio® .NET 2003.
“En la actualidad, las empresas se enfren-
tan a retos importantes para administrar y
automatizar los procesos empresariales cada
vez más desconectados. BizTalk Server 2004
permite a los clientes administrar y automa-
tizar sus procesos empresariales, al tiempo
que brinda a los usuarios herramientas para
diseñar, implementar y supervisar estos pro-
cesos en tiempo real”, dijo Ted Kummert,
vicepresidente corporativo del Grupo de
Servidores E-Business de Microsoft. “Los
primeros usuarios han obtenido gran valor
de sus soluciones BizTalk Server 2004, y el
día de hoy nos emociona poder ofrecer los
mismos resultados a más clientes”.
Nuevas características que organi-
zan y administran los procesos empre-
sariales de principio a fin Además de las
capacidades de integración de aplicaciones

contenidas en las versiones anteriores,
BizTalk Server 2004 brinda nuevas capaci-
dades que permiten a las empresas admi-
nistrar y aplicar reglas a los procesos empre-
sariales, conectarse con los socios comer-
ciales y analizar el estado de los procesos
empresariales en forma más efectiva. Las
nuevas funciones incluidas en BizTalk
Server 2004 incluyen lo siguiente:
• Administración de procesos empresa-
riales (BPM). Ofrece una máquina de
mensajes y organización muy escalable con
capacidad BPM de nivel empresarial,
incluyendo soporte para Business Process
Execution Language (BPEL), un nuevo
estándar para enlazar los procesos empre-
sariales entre los socios comerciales, las
aplicaciones y los usuarios empresariales.
• Integración en Visual Studio .NET
2003. Permite a los desarrolladores cre-
ar, organizar y administrar los procesos
empresariales a través de un ambiente de
desarrollo integrado y muy productivo.
• Supervisión de actividad de estado
(HAT). Permite a los administradores
supervisar y administrar el estado de sus
procesos empresariales dentro de sus
ambientes BizTalk Server.
• Entrada única empresarial. Optimiza el
proceso de verificación de entrada de los

usuarios Windows y no Windows que acce-
den a las aplicaciones de giro empresarial.
• Máquina de normas empresariales muy
escalable. Permite a los analistas empre-
sariales crear normas y políticas flexibles
y de mejor respuesta en torno a los pro-
cesos empresariales.
• Supervisión de actividad empresarial
(BAM). Ofrece a los trabajadores con
información supervisión en tiempo real de
los procesos empresariales a través de
herramientas conocidas como Microsoft
Office Excel o Microsoft Office SharePoint
Portal Server 2003.
• Integración en Microsoft Office
System. Permite el análisis de procesos y
datos.
Microsoft lanza BizTalk Server 2004
dotNetManía
<<
11
Instrucciones de decisión y operadores
de comparación
En algunas de estas instrucciones se utilizan
expresiones que devolverán un valor verdadero
(true) o falso (false).
En esas expresiones podemos utilizar cualquiera
de los operadores condicionales mostrados en la
tabla 8. También podemos formar expresiones múl-
tiples usando los operadores condicionales mos-

trados en esa misma tabla.
En la tabla 9 se muestran algunos ejemplos de
cómo usar las instrucciones de selección o de tomas
de decisiones según usemos
if else
o
switch
case / Select Case
.
En los comentarios se indican algunas de las
peculiaridades de C# y de Visual Basic .NET.
Las instrucciones para realizar bucles
Las instrucciones para realizar bucles nos per-
miten iterar un número determinado (o indeter-
minado) de veces sobre una parte del código. El
código lo incluiremos dentro de dicho bucle.
En C# el código a usar en un bucle puede ser
una sola instrucción, terminada con un punto y
coma, o un bloque de código, incluido dentro de
un par de llaves.
En VB .NET los bucles siempre estarán dentro
de un bloque de código bien delimitado, es decir,
<<
Equivalencia de instrucciones
de C# y VB .NET (y III)
Por Guillermo ‘Guille’ Som
Visual Basic MVP desde 1997
www.elguille.info
Descripción C# VB .NET
Operador de igualdad == =

Distinto != <>
Menor, menor o igual, mayor o mayor o igual son los
mismos operadores en ambos lenguajes: <, <=, >, >=
Y & And
Or |Or
Xor ^ Xor
Negación (not) ! Not
Y cortocircuitado && AndAlso
Or cortocircuitado || OrElse
Tabla 8. Instrucciones (operadores) de comparación
Tercera y última entrega de esta serie de artículos en la que hemos pretendido
explicarle cómo hacer las mismas cosas (o casi) tanto en C# como en Visual
Basic .NET
dotNetManía
<<
12
dnm.lenguajes.net
<<
habrá una parte inicial y otra instruc-
ción que marcará el final de dicho bucle.
En la tabla 10 podemos ver cómo
crear bucles
for
,
do
,
while
así como algu-
nos aspectos a tener en cuenta, ya que
Constructores, destructores

y cómo invocar a los
constructores de una clase
y de la clase base
Los constructores son el punto de
inicio de las clases o tipos de datos, si
en una clase no definimos un cons-
tructor, se creará uno predetermina-
do que simplemente asignarán un
valor inicial a los campos (variables)
que la clase contiene. También pode-
mos crear nuestros propios construc-
tores, de forma que puedan recibir
parámetros para asignar valores a cier-
tos campos de nuestra clase. Incluso
podemos crear distintas versiones de
los constructores para permitir dife-
rentes formas de instanciar (o crear)
nuevos objetos.
En Visual Basic .NET un cons-
tructor se define por medio de un pro-
cedimiento (
Sub
) llamado
New
. En C#
el constructor será un procedimien-
to “especial” que se llama igual que la
propia clase (o tipo) que estamos defi-
niendo.
Por otro lado, un destructor se uti-

liza cada vez que destruimos un obje-
to, en .NET Framework se llama
finalizador, de hecho, en Visual Basic
.NET se utiliza como destructor una
sobrecarga del método
Finalize
decla-
rado en la clase
Object
. En C# el des-
tructor se define usando el nombre
de la clase precedida con
~
. Un des-
tructor se llamará cuando un objeto
deje de estar en “ámbito” o se asigne
un valor nulo a la variable. Hay que
tener en cuenta que en .NET los
objetos no se destruyen inmediata-
mente, sino que cuando dejan de ser
Tarea a realizar C# VB .NET
Toma de decisiones con if if(a != b) <código>; If a <> b Then <código>
Toma de decisiones con if if(a > b){ If a > b Then
con varias instrucciones <código> <código>
} End If
Instrucción if que si se if(a > b) If a > b Then
cumple haga una cosa y si no <código> <código>
se cumple, haga otra, else Else
usando varias líneas <código> <código>
End If

Varias instrucciones if else if(a != b) If a <> b Then
asociadas a otro if. <código> <código>
else ElseIf b > i AndAlso a
> b Then
if(b > i && a > b){
<código>
<código>
Else
}
<código>
End If
Varias instrucciones if anidadas. if(a != b) If a <> b Then
if(b > i) If b > i Then
<código>; <código>
else End If
<código>; Else
<código>
End If
En C# no se distingue entre un if de simple línea o multilínea, pero si queremos usar varias instrucciones en
lugar de una sola acabada con un punto y coma, las incluiremos dentro de un bloque entre un par de llaves {}.
En VB .NET podemos crear un bloque If multilínea acabándola con End If, tanto en el bloque If como en el blo-
que Else o ElseIf podemos indicar una o más líneas con instrucciones. Si no se indica End If se tomará como una
instrucción de una línea, en la que se puede incluir también la parte Else, pero siempre en la misma línea física.
Seleccionar entre varias switch(<expresión>){ Select Case <expresión>
opciones usando switch case <constante1>: Case <valor1>
<código> <código>
break;
case <constante2>: Case <valor2>, <valor3>
case <constante3>: <código>
<código> Case <valorA> To <valorB>

break; <código>
default: Case Is <expresión>
<código> <código>
break; Case Else
} <código>
End Select
En C# sólo se pueden usar valores constantes con cada cláusula case. Podemos anidar una tras otra indicando
varios case seguidos. Después de cada bloque case hay que usar la instrucción break o bien se debe salir del blo-
que de código, ya que no se permite pasar de un case a otro, salvo que usemos goto case <constante>.
En VB .NET en cada cláusula Case se pueden indicar varios valores separados por comas, incluso un rango de
valores usando To o un valor condicional usando Is. Esos valores no tienen porqué ser constantes, pueden ser
también expresiones.
Tabla 9. Instrucciones de decisión
<<
dotNetManía
<<
13
dnm.lenguajes.net
<<
“útiles”, el recolector de basura (reco-
lector de objetos no usados) se encar-
ga de ellos y será el propio GC
(
Garbage Collector
) se encargará de
destruirlo, aunque esa destrucción no
se hará inmediatamente, este punto es
importante ya que si nuestro objeto
mantiene recursos externos éstos no
se liberarán inmediatamente, en esos

casos, es recomendable definir un
método al que llamemos de forma
explícita para liberar esos recursos jus-
to cuando ya no los necesitemos.
Los constructores siempre llama-
rán a un constructor de la clase deri-
vada, si no lo indicamos expresamen-
te, el compilador intentará llamar a
un constructor sin parámetros. En
caso de que la clase base no tenga defi-
nido un constructor sin parámetros,
tendremos que realizar nosotros esa
llamada, indicando el constructor ade-
cuado, si no lo hacemos se producirá
un error de compilación.
Por otra parte, los destructores
siempre llaman al método
Finalize
de
la clase base, de forma que se destru-
yan todos los objetos creados. En este
caso no es necesario que lo llamemos
de forma explícita.
En la tabla 11 podemos ver cómo
definir los constructores y destructo-
res, así como la forma de invocar a
otra sobrecarga de un constructor de
la misma clase e incluso de la clase de
la que se deriva.
Tarea a realizar C# VB .NET

Bucle for for(<inicio>; <final>; For <contador> =
<incremento>) <inicio> To <final>
<código> <código>
Next
Bucle for infinito for(;;) ; For i = 0 To 0 Step 0:
Nota: Espero que a nadie en su Next
sano juicio se le ocurra hacer esto
Bucle for con incremento for(int i = 0; i<10; i For i = 0 To 9 Step 2
distinto de uno. += 2)
<código> <código>
Next
Bucle for para recorrer de mayor for(int i = 10; i>0; i—) For i = 10 To 1 Step -2
a menor. <código> <código>
Next
Salir de un bucle for break; Exit For
En C# podemos indicar varias instrucciones después de if o else incluyéndolas dentro de un bloque entre
un par de llaves {} o bien una sola instrucción acabada con punto y coma.
En VB .NET podemos crear un bloque If acabándola con End If, tanto en la parte If como en la parte Else
podemos indicar una o más líneas con instrucciones. Si no se indica End If se tomará como una instrucción
en una sola línea.
Bucle sin condición de término do{ Do
<código> <código>
}while(true) Loop
Bucle con una condición después do{ Do
de cada iteración, se repetirá <código> <código>
mientras se cumpla la condición }while(<expresión>) Loop While <expresión>
Bucle con una condición al principio while(<expresión>) Do While <expresión>
<código>; <código>
Loop
While <expresión>

<código>
End While
Bucle que continúe la ejecución do{ Do
hasta que se cumpla <código> <código>
la condición }while(! <expresión>) Loop Until <expresión>
Bucle que continúe la ejecución while(! <expresión>){ Do Until <expresión>
hasta que se cumpla la condición, <código> <código>
realizando la comprobación } Loop
al principio del bucle
Salir de un bucle do o while break; Usar Exit seguida del
tipo de bucle:
Exit Do para Do Loop
Exit While para While
End While
En C# los bucles do se utilizan con una instrucción while al final del bucle, esta instrucción es la que se
encarga de comprobar si el bucle debe seguir ejecutándose o no. Si queremos que el bucle se repita indefi-
nidamente podríamos usar una expresión que siempre devuelva un valor verdadero.
En Visual Basic .NET podemos usar la instrucción While o la instrucción Until, en C# no existe la ins-
trucción Until, pero se puede simular usando un while en el que se niega la expresión usada.
En VB .NET se puede usar While como instrucción asociada a Do Loop o como instrucción indepen-
diente, en ese caso el final del bloque del código se indicará con End While.
Tabla 10. Instrucciones de bucles
dotNetManía
<<
14
dnm.lenguajes.net
<<
Definir clases abstractas
y selladas, miembros abs-
tractos y virtuales, redefinir

y ocultar métodos
Las clases abstractas son clases que
sólo se pueden utilizar para derivar
nuevas clases, no se podrán usar para
crear nuevos objetos. Una clase abs-
tracta puede contener métodos y pro-
piedades normales así como abstrac-
tos, los métodos abstractos sólo se
definen como en las interfaces: sin
código que los hagan operativos.
Por otro lado los métodos virtua-
les son los que podremos redefinir en
la clase derivada, para dar la funcio-
nalidad adecuada que creamos conve-
niente. Las referencias a las instancias
creadas en memoria siempre usarán
las versiones redefinidas de los méto-
dos (o miembros) virtuales. Por defec-
to, los métodos y propiedades de una
clase no son virtuales, es decir, no se
pueden redefinir en las clases deriva-
das, sin embargo podemos ocultarlos.
Esos miembros ocultados sólo perte-
necerán a la instancia de la clase que
los define, no a las referencias obte-
nidas a través de tipos de la clase base.
Los miembros abstractos siempre
son virtuales.
También podemos definir clases
selladas, lo contrario de las clases abs-

tractas, es decir, clases que no se pue-
den usar para derivar nuevas clases a
partir de ellas.
También podemos ocultar tipos
además de los miembros de una clase.
En la tabla 12 podemos ver una
lista de las instrucciones usadas para
declarar clases abstractas, miembros
abstractos, virtuales, así como las ins-
trucciones usadas para ocultar miem-
bros y para redefinir los miembros
virtuales de las clases base.
Por supuesto no se han cubierto
todas las posibilidades sintácticas
entre los dos lenguajes más usados de
la plataforma .NET, pero espero que
al menos ahora tengas una idea bas-
tante aproximada de cómo hacer las
tareas más comunes tanto en C#
como en Visual Basic .NET, de for-
ma que en cualquier momento te
resulte fácil poder escribir código en
cualquiera de estos dos lenguajes.
Tarea a realizar C# VB .NET
Definir un constructor de una clase. public Cliente() Public Sub New()
En estos ejemplos, supondremos {} End Sub
que la clase se llama Cliente
Definir un constructor que recibe public Cliente(int id) Public Sub New(id As
un parámetro Integer)
{}

End Sub
Definir un destructor o finalizador ~Cliente() Public Overrides Sub
{} Finalize()
End Sub
En C# el constructor siempre se llama como la clase.
En VB .NET el constructor siempre es un método Sub llamado New.
Los destructores sólo se pueden usar en las clases no en las estructuras.
Definir un constructor que llama a otro public Cliente(int id, Public Sub New(id As
constructor de la propia clase. string nombre) : Integer, nombre As
this(id) String)
{} Me.New(id)
End Sub
Definir un constructor que llama public Cliente(int id, Public Sub New(id As
a otro constructor de la clase base. string nombre) : Integer, nombre As
base(id) String)
{} MyBase.New(id)
End Sub
Tabla 11. Constructores y destructores.
Tarea a realizar C# VB .NET
Definir una clase abstracta abstract class Prueba MustInherit Class
{} Prueba
End Class
Definir una clase sellada sealed class Prueba2 NotInheritable Class
{} Prueba2
End Class
Definir un miembro abstracto abstract void Prueba(); MustOverride Sub
Prueba()
Definir un miembro virtual virtual void Prueba2() Overridable Sub
{} Prueba2()
End Sub

Los miembros abstractos sólo definen el método o propiedad, pero no contienen código que lo defina.
Redefinir un miembro abstracto o override void Prueba() Overrides Sub Prueba()
virtual {}
End Sub
Definir un miembro que oculta new void Prueba3() Shadows Sub Prueba3()
a otro de la clase base {} End Sub
En VB .NET si se quiere ocultar un miembro virtual, además de usar Shadows debemos usar la instruc-
ción Overloads.
Nota sobre seguridad: Los miembros declarados como virtual internal (Overridable Friend en VB) en teo-
ría sólo se pueden reemplazar en clases definidas en el propio ensamblado, pero esa “restricción” sólo es
aplicable a los compiladores de C# y de VB, el CLR no tiene esa restricción, por tanto es teóricamente posi-
ble reemplazar esos miembros desde otro ensamblado, al menos por compiladores que no tengan dicha res-
tricción. Para más información: /cpguide/html/cpconkeyconceptsinsecurity.htm
/cpguide/html/cpconsecurityconcernsforinternalvirtualoverloadsoverridablefriendkeywords.htm
Tabla 11. Constructores y destructores.
dotNetManía
<<
16
ASP.NET
esto ha cambiado y nos permite realizar
una configuración de las aplicaciones
Web basada en ficheros en formato
XML. Este sistema de configuración de
ASP.NET hace uso de dos tipos de
ficheros de configuración:
1. Configuración del servidor: Que se alma-
cena en un fichero denominado machi-
ne.config. Este fichero va a representar
la configuración por defecto de todas

las aplicaciones ASP.NET existentes
en el servidor y se localiza en el direc-
torio Windows \Microsoft.NET
\Framework\[versión]\config.
2. Configuración de la aplicación: Se almace-
na en el fichero web.config. Un servidor
Web puede contener varios ficheros
web.config, cada uno de ellos dentro del
directorio raíz de cada una de las apli-
caciones ASP.NET del servidor. La con-
figuración indicada dentro de un fiche-
ro web.config sobrescribe los valores espe-
cificados en el fichero machine.config.
Ventajas
Este nuevo mecanismo de configu-
ración que encontramos en la platafor-
ma .NET para configurar las aplicacio-
nes Web de ASP.NET, aporta las
siguientes ventajas:
• Valores de configuración en formato
legible: Es muy sencillo abrir un
fichero XML y leer o modificar la
configuración.
• Actualizaciones inmediatas: Las
modificaciones realizadas en la
configuración de las aplicaciones
se aplican de forma inmediata sin
necesidad de reiniciar el servidor
Web o parar los servicios.
• Configuraciones fácilmente repetibles:

Para tener una aplicación
ASP.NET con la misma configu-
ración que otra aplicación distin-
ta, únicamente debemos copiar los
ficheros de configuración en el
directorio de la aplicación corres-
pondiente.
• Bloqueo de valores de configuración:
Podemos bloquear los valores de
configuración que deseemos para
que no sean sobrescritos.
• ASP.NET configura de manera
automática el servidor Web IIS para
que no sea posible que un cliente
realice una petición a un fichero
web.config, y de esta forma pueda ver
la configuración de nuestra aplica-
ción ASP.NET
Proceso de obtención
de la configuración de una
aplicación Web
A continuación se va a comentar el
proceso que sigue la plataforma .NET
para obtener y aplicar la configuración
final de una aplicación ASP.NET.
A la hora de obtener la configura-
ción se produce una fusión entre los
ficheros machine.config y web.config. Los
valores de configuración se heredan
entre distintas aplicaciones ASP.NET,

siendo el fichero machine.config la con-
figuración raíz de la que heredan el
resto.
Por lo tanto, en primer lugar tene-
mos el fichero machine.config que afec-
tará a todas las aplicaciones ASP.NET
existentes en el servidor Web. A los valo-
res de configuración indicados en este
fichero se le añadirían o sobrescribirí-
an los presentes en el fichero web.config
que posee un sitio Web, que actúa como
una aplicación ASP.NET.
Configuración de aplicaciones
Web de ASP.NET
Por Ángel Esteban
Software Arquitect
Alhambra-Eidos
En versiones anteriores de la tecnología ASP,la configuración de aplicaciones Web se rea-
lizaba a través del administrador de servicios de Internet (Internet Information Server,
IIS), ya que la información relativa a la configuración de aplicaciones ASP se almacenaba
en un repositorio binario denominado metabase de Internet Information Server. Se tenía
que acceder a las distintas hojas de propiedades que nos ofrecía IIS para poder configu-
rar nuestra aplicación.
Pero en la tecnología
<<
Si dentro de este sitio Web tenemos
definida una aplicación ASP.NET, que
ofrece su propio fichero web.config, éste
se combinaría con el fichero XML pre-
sente en el sitio Web predeterminado.

Y así podríamos seguir una cadena de
combinación de ficheros web.config.
Formato de los ficheros de
configuración de una
aplicación ASP.NET
Tenga a mano el contenido de un
fichero machine.config y web.config para
seguir el artículo de forma más senci-
lla y conseguir un mayor aprovecha-
miento del mismo.
Los ficheros machine.config y el fiche-
ro web.config internamente presentan el
mismo formato XML. El elemento raíz
es siempre <configuration>. Dentro de
éste podemos encontrar dos secciones
generales: Sección de los manejadores y
sección de los valores de configuración.
Sección de los manejadores
Identifican las clases de .NET
Framework que se utilizarán cuando el
sistema de configuración se carga. Esta
sección se encuentra entre las etiquetas
<configSections>. La función de estas cla-
ses es la de leer los valores de la sección
de los valores de configuración que les
corresponda.
El atributo name de la etiqueta <sec-
tion> define el nombre de la etiqueta del
elemento de la sección de los valores de
configuración del que se va a encargar

el manejador, cuya clase especificamos
en el atributo type, dentro de este atri-
buto además se indica el assembly en el
que se encuentra la clase junto con su
versión correspondiente.
Si se desea definir manejadores para
una sección de valores de configuración
que a su vez va a tener varias secciones,
las distintas etiquetas <section> irán inclui-
das entre las etiquetas <sectionGroup>.
En el fuente 1 se muestra un frag-
mento del fichero machine.config que se
corresponde con la definición de dos
manejadores para las secciones
sessionState y trace, que a su vez perte-
necen al grupo <system.web>, también se
define el manejador para la sección
appSettings. El grupo <system.web> va a
ser de gran interés, ya que nos va a per-
mitir configurar los distintos aspectos
de nuestras aplicaciones ASP.NET.
Una vez que se ha declarado la sec-
ción de los manejadores no es necesa-
rio volver a declararla en los ficheros
web.config, ya que si se encuentran en el
fichero machine.config, o en un fichero
web.config de nivel superior, la hereda-
rán de manera automática.
Sección de los valores
de configuración

Mientras que la sección de los
manejadores define clases, la sección
de valores de configuración identifica
las propiedades que afectan al com-
portamiento de la aplicación ASP.NET.
En muchos de los casos necesitaremos
saber únicamente el significado de la
opción que vamos a modificar.
Normalmente los valores de configu-
ración de la aplicación ASP.NET no los
vamos a indicar en el fichero machine.con-
fig, ya que estos valores afectarán a todas
las aplicaciones ASP.NET del servidor,
sino que utilizaremos un fichero web.con-
fig particular para una aplicación ASP.NET
determinada. En este fichero web.config
heredaremos la sección de los manejado-
res indicada en el fichero machine.config.
Tareas de configuración
más comunes
Si examinamos detenidamente el
fichero de configuración machine.config
que tenemos en nuestro equipo, pode-
mos encontrar alrededor de treinta
opciones de configuración distintas. En
este artículo no vamos a tratar todas
estas tareas de configuración, sino que
vamos a ver las más comunes y las que
más se pueden usar en un entorno real
de trabajo.

Todas estas opciones de configura-
ción se encontrarán dentro de la sección
de los valores de configuración del fiche-
ro de configuración correspondiente,
que por lo general será el fichero
web.config.
Configuración general
En esta sección se va a indicar una serie
de parámetros de configuración genéri-
cos para la aplicación ASP.NET. Para ello
se hace uso de la etiqueta <httpRuntime>.
Esta etiqueta tiene como más significati-
vos los siguientes atributos:
• executionTimeout: En este atributo
indicaremos en segundos el tiempo
de espera que se aplicará a la ejecu-
ción de un recurso solicitado. Una
dotNetManía
<<
17
dnm.asp.net
<<
<?xml version=”1.0” encoding=”UTF-8” ?>
<configuration>
<configSections>
<section name=”appSettings”
type=”System.Configuration.NameValueFileSectionHandler,System,
Version=1.0.2411.0, Culture=neutral,PublicKeyToken=b77a5c561934e089” />
<sectionGroup name=”system.web”>
<section name=”sessionState”

type=”System.Web.SessionState.SessionStateSectionHandler, System.Web,
Version=1.0.2411.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a”
allowDefinition=”MachineToApplication” />
<section name=”trace”
type=”System.Web.Configuration.TraceConfigurationHandler, System.Web,
Version=1.0.2411.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a” />
</sectionGroup>
</configSections>
… … … …
</configuration>
Fuente 1. Definición de manejadores para las secciones sesionState y trace
vez sobrepasado este tiempo de
espera la aplicación ASP.NET fina-
lizará la ejecución del recurso. Por
defecto es 90 segundos.
• maxRequestLength: Indica en Kb el
tamaño máximo de una petición.
Por defecto es 4.099 Kb.
• userFullyQualifiedRedirectUrl: Indica
si al cliente se le va a devolver una
URL completa o una URL relati-
va. Por defecto es false, por lo que
se enviará una URL relativa.
Configuración de la página
Mediante la etiqueta <pages> pode-
mos controlar algunos de los compor-
tamientos de las páginas ASP.NET
presentes en una aplicación. La eti-
queta <pages> puede tener los siguien-

tes atributos:
• autoEventWireup: Indica si los even-
tos de la página se van a lanzar de for-
ma automática. Por defecto es true.
• buffer: Se utilizará para activar o
desactivar el búfer de las páginas
ASP.NET de la aplicación actual.
Puede tomar valores true/false.
• enableSessionState: Este atributo per-
mite activar o desactivar el estado de
sesión, es decir, permite o no la uti-
lización del objeto Session para alma-
cenar información común a la sesión
actual del usuario con la aplicación
Web. Puede tomar valores true/false.
• enableViewState: Permite activar o
desactivar el mantenimiento auto-
mático de los valores de los contro-
les Web dentro de los formularios
Web. Por defecto es true.
Estos atributos se corresponden con
los atributos del mismo nombre de la
directiva @Page, por lo que utilizando
esta directiva podemos sobrescribir estos
valores de configuración para una pági-
na ASP.NET en concreto.
Configuración de la aplicación
En esta sección vamos a poder alma-
cenar valores de detalles de configuración
de la aplicación. Para almacenar estos

parámetros dentro del fichero de confi-
guración vamos a utilizar pares clave/valor.
Estos valores de configuración defi-
nidos en la sección <appSettings> los
vamos a poder recuperar en las páginas
ASP.NET de la aplicación. Esta etiqueta
de configuración de la aplicación no se
encuentra dentro de la sección <sys-
tem.web>.
Dentro de la etiqueta <appSettings>
tenemos unas subetiquetas <add>.
Existirá una etiqueta <add> por cada
parámetro o valor que queremos indi-
car en la aplicación, esta etiqueta posee
dos atributos: key, que es la clave con la
que después vamos a poder acceder a
este parámetro a través de la colección
AppSettings, y value que va a ser el valor
que le vamos a asignar al parámetro.
En el fuente 4 se muestra el frag-
mento de un fichero web.config en el que
se definen dos parámetros para la apli-
cación: Se indica una cadena de cone-
xión y una sentencia SQL.
Configuración de la sesión
Desde el fichero de configuración
de la aplicación ASP.NET tenemos la
posibilidad de configurar la forma en la
que se va a utilizar el estado de sesión
mediante la etiqueta <sessionState>. Para

ello presenta los siguientes atributos:
• mode: Indica el modo de almacena-
miento utilizado para el proceso que
se corresponde con el estado de la
sesión. Los valores que podemos
asignar a este atributo son: InProc,
el estado de sesión se encuentra en
el proceso actual de ASP.NET; Off,
el estado de sesión se encuentra
desactivado; SQLServer, se utiliza
un proceso de SQL Server para
almacenar el estado; StateServer, se
utiliza un proceso en forma de ser-
vicio de Windows para almacenar
el estado. Por defecto es InProc.
• stateConnectionString: En este atri-
buto se indica la dirección IP y el
número de puerto utilizados para
comunicarse con el servicio de
Windows que ofrece las facilidades
de almacenamiento. Este atributo
únicamente tiene sentido utilizarlo
cuando el atributo mode tiene el
valor de StateServer.
• sqlConnectionString: Identifica la
cadena de conexión de la base de
datos utilizada para almacenar el
estado cuando el atributo mode
posee el valor SQLServer. Esta cade-
na debe incluir la dirección IP y el

nombre y contraseña de usuario
para conectar a la base de datos de
SQL Server.
• cookieless: Atributo que indica si el
objeto Session utiliza cookies para
almacenar el identificador de sesión,
o por el contrario no las utiliza y el
identificador de sesión lo va mante-
niendo a través del mecanismo de
URLs. El mecanismo de URLs será
utilizado cuando el valor de este atri-
buto sea true. Por defecto es false.
• timeout: El atributo timeout especifi-
ca, en minutos. el intervalo de inac-
tividad para el objeto Session. Si el
usuario no actualiza o solicita una
página durante ese intervalo, la sesión
termina. Por defecto es 20 minutos.
dotNetManía
<<
18
dnm.asp.net
<<
<configuration>
<system.web>
<pages buffer=”true” enableSessionState=”true”
enableViewState=”true” autoEventWireup=”true”/>
</system.web>
</configuration>
Fuente 2. Ejemplo de uso de la etiqueta <pages>

<configuration>
<appSettings>
<add key=”conexion” value=”server=aesteban;database=datos;uid=sa;pwd=”/>
<add key=”sentencia” value=”select nombre, apellidos,email from
Usuarios”/>
</appSettings>
</configuration>
Fuente 3. Ejemplo de uso de la etiqueta <appSettings>
dotNetManía
<<
19
dnm.asp.net
<<
Globalización
Los valores indicados en la sección
<globalization> nos va a permitir confi-
gurar las opciones de codificación y cul-
tura. La etiqueta <globalization> nos
ofrece cinco atributos para indicar diver-
sos aspectos de la codificación utilizada
en nuestra aplicación:
• requestEncoding: Mediante este atri-
buto podemos indicar la codifica-
ción utilizada en cada solicitud. Por
defecto tiene la codificación utf-8.
• responseEncoding: Este atributo tie-
ne el mismo significado que el ante-
rior pero aplicado a una respuesta
enviada al cliente. Por defecto tie-
ne la codificación utf-8.

• fileEncoding: Permite indicar el tipo
de codificación aplicado a los fiche-
ros. Por defecto tiene la codifica-
ción utf-8.
• culture: Podemos especificar el lugar
en el que nos encontramos para que
se aplique a las cadenas el idioma ade-
cuado, así como también a las fechas
y su formato. Por ejemplo,
en-US
representa al idioma inglés de Estados
Unidos y
fr-FR
francés en Francia.
• uiCulture: Indica la misma infor-
mación que en el atributo anterior,
pero se va a utilizar para realizar
búsquedas en las cadenas del idio-
ma correspondiente.
Identidad de la aplicación
En la sección <identity> vamos a
poder configurar la identidad del pro-
ceso que ejecuta ASP.NET en el servi-
dor. Para ello esta etiqueta nos ofrece
los siguientes atributos:
• impersonate: Si posee el valor true indi-
ca que el proceso de ASP.NET se va
a ejecutar bajo la identidad por defec-
to, el usuario IUSR_NombreServidor,
o bien bajo el usuario que nosotros le

indiquemos. Por defecto es false.
• name: Este atributo estará disponi-
ble cuando el atributo impersonate
tenga el valor true, y lo vamos a uti-
lizar cuando deseemos indicar una
cuenta de usuario de Windows espe-
cífica para representar al proceso de
ejecución de ASP.NET.
• password: En él indicaremos la con-
traseña del usuario que se va a uti-
lizar en el proceso.
En el fuente 6 se puede observar el
uso de esta etiqueta. En este caso se indi-
ca que utilice como identidad del proce-
so de ASP.NET un usuario de Windows.
Si quisiéramos utilizar el usuario de IIS,
le asignaríamos el valor de cadena vacía
a los atributos name y password:
Configuración de trazas
La configuración del mecanismo de
trazas que de ASP.NET se hace a tra-
vés del uso de la etiqueta <trace> que tie-
ne los siguientes atributos:
enabled: Este atributo indica si el
mecanismo de trazas se encuentra acti-
vado a o no. Tiene por lo tanto la mis-
ma funcionalidad que el atributo de mis-
mo nombre de la directiva @Page. Su
valor por defecto es false.
requestLimit: En este atributo indi-

caremos el número máximo de peti-
ciones HTTP de las que se va a alma-
cenar información de trazas. Las tra-
zas van a ser almacenadas en un regis-
tro de trazas mediante un mecanismo
circular en las que permanecerán las
últimas n peticiones. Por defecto es
10.
• pageOutput: Indica si la información
de trazas se va a mostrar al final de
cada página ASP.NET, tal como se
hace con las trazas a nivel de pági-
na. Por defecto es false.
• traceMode: Este atributo nos permite
indicar el modo de ordenación de los
mensajes de trazas en la sección
Información de seguimiento. Puede pre-
sentar los valores SortByCategory y
SortByTime. Por defecto es SortByTime.
• localOnly: Indica si la información
de trazas se muestra únicamente a
los clientes locales o por el con-
trario, se muestra también a los
clientes remotos. Por defecto es
false.
Le animo a que siga investigando las
numerosas posibilidades de configura-
ción para las aplicaciones Web que ofre-
ce ASP.NET. Lo mejor es empezar por
observar los contenidos de los ficheros

de configuración.
<configuration>
<system.web>
<globalization requestEncoding=”utf-8” responseEncoding=”utf-8”
culture=”es-ES” uiCulture=”es-ES”/>
</system.web>
</configuration>
Fuente 4. Ejemplo de la sección <Globalization>.
<configuration>
<system.web>
<identity impersonate=”true” user=”aesteban” password=”xxx”/>
</system.web>
</configuration>
Fuente 5. Ejemplo de la sección <Identity>.
<configuration>
<system.web>
<trace enabled=”false” localOnly=”true” pageOutput=”false” requestLimit=”10”
traceMode=”SortByTime” />
</system.web>
</configuration>
Fuente 6. Ejemplo de la sección <trace>.
dotNetManía
<<
20
cual es esa problemática y
posteriormente qué alternativas tenemos para
tratarla. El problema fundamental que se nos
plantea son los conflictos de concurrencia. Un
conflicto de concurrencia se produce cuando un
usuario modifica un registro de una tabla de una

base de datos y ese registro ha cambiado desde
la última vez que lo leyó. Por ejemplo, conside-
remos la siguiente secuencia de sucesos:
• Los usuarios A y B leen el registro R1 de
la base de datos cargándolo en un DataSet.
• El usuario A modifica R1
• El usuario A guarda R1 en la base de datos.
• El usuario B modifica R1
• El usuario B guarda R1 en la base de datos.
• El usuario B recibe una excepción
DBConcurrencyException, indicando un con-
flicto de concurrencia al haber sido modi-
ficado R1 desde la última vez que B lo leyó.
Los conflictos de concurrencia no se produ-
cen solamente al actualizar un registro porque
otro usuario lo haya modificado, también ocu-
rren si el registro ha sido eliminado por otro usua-
rio. Asimismo, tienen lugar cuando un usuario
intenta eliminar un registro que ha sido modifi-
cado e incluso que ha sido eliminado. Con la
inserción, sin embargo, es evidente que no se pro-
ducen conflictos de concurrencia, ya que es impo-
sible que otro usuario pueda modificar un regis-
tro que aún no existe en la base de datos. En defi-
nitiva, los conflictos de concurrencia pueden pro-
ducirse:
• Al modificar un registro
• Al eliminar un registro
Y la causa del conflicto puede ser porque
dicho registro:

• Ha sido modificado desde la última vez que
se leyó.
• Ha sido eliminado desde la última vez que
se leyó.
Otro aspecto básico acerca de los conflictos
de concurrencia es la forma de detectarlos. La
técnica de detección se basa fundamentalmente
en incluir en la cláusula WHERE de la instruc-
ción UPDATE o DELETE el valor original de
los campos, es decir, el valor que tenían los cam-
pos del registro cuando se leyeron de la base de
datos. Pongamos un ejemplo para aclarar ideas.
Gestión de concurrencia en ADO.NET
Por Jesús López Méndez
(SqlRanger)
La concurrencia, en un entorno multiusuario, es siempre una cuestión proble-
mática, pero si además se trata de un entorno desconectado como el que se
usa en ADO.NET con sus DataSets y DataAdapters,la problemática es aún mayor
debido a la propia naturaleza desconectada del entorno.
Veamos, en primer lugar,
<<
Supongamos que estamos trabajando
con la siguiente tabla en una base de
datos de SQL Server:
El comando UPDATE que detec-
ta conflictos de concurrencia sería el
siguiente:
Como veis, están todos los valores
originales en la cláusula WHERE de
esta instrucción parametrizada. De

esta manera, si ha cambiado alguno
de los campos, no se cumplirá la con-
dición, y por tanto la instrucción no
actualizará ningún registro, o lo que
es lo mismo, el número de registros
afectados será cero. Solamente la ins-
trucción tendrá éxito, o sea, actuali-
zará el registro, si éste no ha cambia-
do. Así es como ADO.NET detecta
los conflictos de concurrencia, con-
cretamente un DataAdapter lanzará
una excepción DBConcurrencyException
cuando el comando de actualización
afecte a cero registros. Observad que
este comando incluye todos los cam-
pos en la cláusula SET, excepto el
IdEmpleado que es autonumérico y por
tanto de sólo lectura. Esto viene a
suponer que se actualizarán todos los
campos en la tabla, independiente-
mente de si se han modificado o no,
lo que implica una falta de optimiza-
ción.
Sin embargo, es posible que no nos
interese detectar conflictos de concu-
rrencia y que queramos que la actua-
lización se lleve a cabo independien-
temente de si el registro ha sido modi-
ficado o no desde la última vez que se
leyó. En ese caso sólo incluiríamos la

clave primaria en la cláusula WHERE.
La instrucción UPDATE sería la
siguiente:
Aún así, podríamos obtener un
conflicto de concurrencia, pero sólo
en el caso de que haya sido eliminado
el registro. Un inconveniente de esta
opción es que es posible perder modi-
ficaciones. Si por ejemplo, los usua-
rios A y B leen el empleado 10, el
usuario A modifica su nombre y lo
guarda, y luego B modifica el apelli-
do y lo guarda, las dos actualizaciones
tienen éxito, pero la modificación que
hizo A se pierde, ya que el nombre es
sobrescrito con el valor que leyó B.
En ciertos sistemas, esta posible pér-
dida de modificaciones es inaceptable
y por tanto habría que elegir otra
opción.
Otra alternativa sería incluir en la
cláusula SET sólo los campos que se
han modificado. De esta manera, aun-
que sólo incluyéramos la clave pri-
maria en la cláusula WHERE, no se
perderían las modificaciones. También
es una opción interesante incluir en
la cláusula SET sólo los campos modi-
ficados, y en la cláusula WHERE la
clave primaria más el valor original de

los campos que han cambiado, así el
conflicto de concurrencia que detec-
taríamos sería en el caso de que otro
usuario hubiera modificado alguno de
los campos que han sido modificados
o en el caso de eliminación. Por ejem-
plo, si los usuarios A y el B leen el
empleado 10, el usuario A modifica su
nombre y lo guarda y el usuario B
modifica su nombre y lo guarda, el
usuario B recibe un conflicto de con-
currencia. Pero si lo que ocurre es que
el usuario A modifica el nombre y el
B el apellido, no hay conflicto de con-
currencia y las dos actualizaciones tie-
nen éxito.
Una última alternativa para la cláu-
sula WHERE es incluir la clave pri-
maria más el valor original de un cam-
po de tipo TimeStamp que por supues-
to tendría que formar parte de la tabla.
El funcionamiento es equivalente a
incluir los valores originales de todos
CREATE TABLE Empleados (
IdEmpleado INT IDENTITY(1,1) PRIMARY KEY,
DNI VARCHAR(12) NOT NULL UNIQUE,
Nombre VARCHAR(50) NOT NULL,
Apellidos VARCHAR(50) NOT NULL
)
UPDATE Empleados

SET DNI=@DNI, Nombre=@Nombre, Apellidos=@Apellidos
WHERE IdEmpleado=@Original_IdEmpleado AND DNI=@Original_DNI AND
Nombre=@Original_Nombre AND Apellidos=@Original_Apellidos
UPDATE Empleados
SET DNI=@DNI, Nombre=@Nombre, Apellidos=@Apellidos
WHERE IdEmpleado=@Original_IdEmpleado
Los conflictos de concurrencia no se producen
solamente al actualizar un registro porque otro usuario
lo haya modificado, también ocurren si el registro
ha sido eliminado por otro usuario
dotNetManía
<<
21
dnm.ado.net
<<
dotNetManía
<<
22
dnm.ado.net
<<
los campos, pero resulta más eficiente ya que la ins-
trucción es más corta, reduciéndose el tráfico de
red y reduciendo el trabajo del procesador de con-
sultas del servidor de base de datos. Un campo de
tipo TimeStamp en SQL Server es una especie de
autonumérico de 64 bits único en toda la base de
datos. No puede haber dos registros en una base de
datos con el mismo valor de TimeStamp, incluso
aunque pertenezcan a distintas tablas. Cada vez que
se modifica un registro que tiene un campo

TimeStamp, el valor del campo también cambia.
Debido a esto y si usamos esta alternativa, después
de modificar un registro, sería necesario volver a
leer el campo TimeStamp para poder realizar más
modificaciones en el mismo registro.
Detectar conflictos de concurrencia en la eli-
minación es similar a la actualización, con la salve-
dad de que en este caso sólo podemos jugar con la
cláusula WHERE de la instrucción DELETE.
Podríamos incluir sólo la clave primaria, en cuyo
caso sólo obtendremos conflictos de concurrencia
cuando otro usuario haya eliminado el registro. En
la mayoría de los casos, este conflicto sencillamen-
te lo podríamos ignorar. También podríamos incluir
todos los valores originales de los campos o la cla-
ve primaria más el TimeStamp, en cuyo caso reci-
biremos un conflicto de concurrencia cuando otro
usuario haya modificado o eliminado el registro.
Una vez que tenemos decidido cómo vamos a
detectar los conflictos de concurrencia y cómo
vamos a hacer las actualizaciones y eliminaciones,
hemos de decidir cómo los vamos a tratar, o sea,
qué acciones vamos a tomar en el caso de un con-
flicto de concurrencia. Cada conflicto de concu-
rrencia lo trataremos de manera diferente en fun-
ción de si se ha producido al hacer una actualiza-
ción o al realizar una eliminación y en función de
la causa del conflicto, esto es, si ha sido porque
otro usuario lo ha modificado o porque lo ha eli-
minado.

Empecemos primero por los conflictos que se
producen al actualizar. Si la causa es que otro usua-
rio lo ha modificado podríamos tener las siguien-
tes alternativas:
• Descartar las modificaciones y refrescar el registro
volviéndolo a leer de la base de datos. Al usuario
le avisaríamos del conflicto de concurrencia y
le daríamos la oportunidad de volver a hacer
las modificaciones.
• Refrescar sólo los valores originales sin descartar las
modificaciones. Al usuario le avisaríamos del con-
flicto. Entonces él tendría la oportunidad de
ver las modificaciones deshaciendo cambios o
de volver a guardar con lo que forzaría la actua-
lización.
• Directamente forzar la actualización. Esto se
conoce como la técnica “el último que llega
gana”. En realidad esta acción no es una res-
puesta a un conflicto de concurrencia, ya que
para llevarla a cabo incluiríamos únicamente
la clave primaria en la cláusula WHERE, no
detectándose conflictos de concurrencia por
modificación.
Si la causa es que otro usuario lo ha eliminado,
las alternativas serían las siguientes:
• Volver a insertar el registro en la base de datos. En
el caso de que tengamos un autonumérico en
la tabla no sería posible volver a insertar el
registro exactamente igual a como era ante-
riormente.

• Eliminarlo del DataSet. Esta es la opción que
más se suele utilizar.
Detectar la causa del conflicto, al igual que
refrescar un registro, puede realizarse volviendo a
leer tal registro de la base de datos basándose en la
clave primaria, pero si la clave primaria puede cam-
biar, esta técnica no sirve para su propósito ya que
si ésta ha cambiado no es posible identificar el regis-
tro y no es posible determinar si el conflicto de con-
currencia ha ocurrido por modificación o por eli-
minación. Por eso sería recomendable usar claves
primarias artificiales como autonuméricos o
GUID’s.
En cuanto a los conflictos de concurrencia que
se producen al eliminar un registro, podríamos tener
las siguientes alternativas cuando la causa es por
modificación:
• Deshacer la eliminación y refrescar el registro. Al
usuario le informaríamos del conflicto y ten-
dría la posibilidad de volverlo a eliminar des-
pués de haber visto los cambios realizados.
La técnica de detección se basa fundamentalmente
en incluir en la cláusula WHERE
de la instrucción UPDATE o DELETE
el valor original de los campos
• Forzar la eliminación. En realidad
esta acción no es una respuesta a
un conflicto de concurrencia, ya
que para llevarla a cabo incluiría-
mos únicamente la clave primaria

en la cláusula WHERE con lo que
no se detectan conflictos de con-
currencia por modificación.
Por último, el conflicto de concu-
rrencia que se produce al eliminar un
registro que ha sido eliminado, gene-
ralmente puede tratarse sencillamen-
te ignorando el conflicto y eliminan-
do definitivamente el registro del
DataSet.
Como hemos visto, existen varias
alternativas para detectar y tratar los
conflictos de concurrencia. Veamos
ahora qué nos ofrece ADO.NET en
este sentido.
En ADO.NET tenemos una serie
de clases, los DataAdapters, que son
los encargados de revertir las modi-
ficaciones realizadas en un DataSet
sobre la base de datos mediante su
método Update. Los DataAdapters tie-
nen tres propiedades: DeleteCommand,
UpdateCommand e InsertCommand que
son los comandos de actualización.
Estos comandos son parametrizados,
de manera que sirvan para todas las filas
de un DataTable. Cuando invocamos al
método Update de un DataAdapter, éste
recorre todas las filas del DataTable, y
si la fila es una fila eliminada, ejecuta

el DeleteCommand; si la fila es una fila
modificada, invoca el UpdateCommand;
y si es una fila nueva, invoca al
InsertCommand. Si al invocar al Update-
Command o al DeleteCommand, el
número de registros afectados es cero,
el DataAdapter lanza una excepción
DBConcurrencyException indicando que
se ha producido un conflicto de con-
currencia. Antes de invocar un coman-
do de actualización, el DataAdapter
establece el valor de los parámetros del
comando con los valores originales o
actuales de los campos de la fila basán-
dose en la configuración del propio
comando. Cada parámetro de la colec-
ción Parameters de un comando tiene
la propiedad SourceColumn que indica
el nombre del campo cuyo valor debe-
rá copiarse al parámetro, y la propie-
dad SourceVersion que indica si se trata
del valor actual o del valor original.
Antes de poder invocar al método
Update de un DataAdapter tenemos
que configurarlo correctamente, esto
es, tenemos que establecerle los
comandos de actualización. Para con-
figurar un DataAdapter tenemos tres
alternativas:
• Usar el asistente para la configu-

ración del DataAdapter
• Usar un CommandBuilder
• Configurarlo manualmente
escribiendo nosotros mismos el
código
Para usar el asistente, sólo tene-
mos que arrastrar un DataAdapter
de la ficha datos del cuadro de
herramientas a nuestro formulario
o componente y seguir sus instruc-
ciones. En el paso “Generar las ins-
trucciones SQL” tenemos un botón
“Opciones avanzadas” que nos pre-
senta el cuadro de diálogo de la
figura 1.
Como vemos, el asistente puede
generar por nosotros los comandos de
actualización INSERT, UPDATE y
DELETE. Si elegimos “Usar concu-
rrencia optimista”, el asistente inclui-
rá en la cláusula WHERE de las ins-
trucciones UPDATE y DELETE el
valor original de todos los campos del
registro. Mientras que si no activamos
esa casilla de verificación, la cláusula
WHERE sólo incluirá la clave prima-
ria. Si elegimos “Actualizar el con-
junto de datos” el asistente añade una
instrucción SELECT a los comandos
de actualización para refrescar el regis-

tro. En cualquier caso, la instrucción
UPDATE incluye en la cláusula SET
todos los campos.
Esta sería la instrucción UPDA-
TE para nuestra tabla de ejemplo
usando concurrencia optimista. Ver
tabla 1.
Figura1. Opciones avanzadas de generación de instrucciones SQL.
UPDATE Empleados
SET DNI=@DNI, Nombre=@Nombre, Apellidos=@Apellidos
WHERE IdEmpleado=@Original_IdEmpleado AND DNI=@Original_DNI AND
Nombre=@Original_Nombre AND Apellidos=@Original_Apellidos
Tabla 1
dotNetManía
<<
23
dnm.ado.net
<<
dotNetManía
<<
24
dnm.ado.net
<<
Y esta sería la instrucción UPDATE sin usar la
concurrencia optimista:
Como hemos dicho anteriormente, también
podemos usar un CommandBuilder. Este sería el
código a usar para nuestra tabla de ejemplo:
Las instrucciones UPDATE y DELETE serían
equivalentes a las generadas por el asistente usan-

do concurrencia optimista y sin actualizar el con-
junto de datos.
La alternativa de configurar manualmente el
DataAdapter no es muy recomendable, ya que
requiere escribir bastante código y la funcionalidad
obtenida es exactamente igual a la conseguida usan-
do el asistente. Además es posible que cometamos
algún error al escribir el código, mientras que el
asistente no los comete.
Como vemos, el DataAdapter sólo nos deja la posi-
bilidad de incluir en la cláusula WHERE de las ins-
trucciones UPDATE y DELETE o bien la clave pri-
maria, o bien todos los campos. No tenemos las otras
alternativas que se mencionan en este artículo. Además
en la cláusula SET de la instrucción UPDATE, sólo
podemos incluir todos los campos, no tenemos la
opción de incluir sólo los modificados.
Por otra parte, ADO.NET sólo da soporte para
la detección del conflicto de concurrencia, no hay
nada que nos ayude a gestionarlo, por lo que ten-
dremos que escribir nosotros mismos el código
necesario.
El código de ejemplo del fuente 1 muestra como
gestionar conflictos de concurrencia, refrescando
el registro si ha sido modificado y eliminándolo si
ha sido eliminado.
Como vemos, gestionar los conflictos de concu-
rrencia no es trivial y repetir el mismo código una y
otra vez para cada caso es muy laborioso y pesado.
Una buena alternativa a los DataAdapters que vie-

nen incluidos en .NET Framework, es escribir nues-
tro propio DataAdapter que no tenga estas limita-
ciones, que sea capaz de gestionar los conflictos de
concurrencia y que disponga de todas las opciones
mencionadas en este artículo. Podéis encontrar un
DataAdapter para SQL Server (SqlRanger.SqlAdapter)
escrito por mí en la web de la revista o en mi propia
página web: />Este DataAdapter es completamente gratis y se
incluye el código fuente así como un ejemplo de su
uso. El SqlRanger.SqlAdapter tiene propiedades espe-
cíficas para tratar la concurrencia. Entre las que se
incluyen:
• UpdateCriteria: Determina los campos a incluir
en la cláusula WHERE de la instrucción
UPDATE. Puede tomar los siguientes valores:
• All: Se incluirán los valores originales de
todos los campos.
• Key: Se incluirá sólo la clave primaria.
• Modified: Se incluirá la clave primaria más
los valores originales de los campos modi-
ficados.
• TimeStamp: Se incluirá la clave primaria más
el valor original del campo TimeStamp si es
que existe.
• UpdateColumns: Determina qué campos apa-
recerán en la cláusula SET de la instrucción
UPDATE. Puede tomar los siguientes valores:
• All: Se incluyen todos los campos.
• Modified: Se incluyen sólo los campos modi-
ficados.

• DeleteCriteria: Determina los campos a incluir
en la cláusula WHERE de la instrucción DELE-
TE. Puede tomar los siguientes valores:
• All: Se incluirán los valores originales de
todos los campos.
• Key: Se incluirá sólo la clave primaria.
• TimeStamp: Se incluirá la clave primaria más
el valor original del campo TimeStamp si es
que existe.
UPDATE Empleados
SET DNI=@DNI, Nombre=@Nombre, Apellidos=@Apellidos
WHERE IdEmpleado=@Original_IdEmpleado
SqlDataAdapter Adapter = new SqlDataAdapter(“SELECT * FROM Empleados”, Connection);
SqlCommandBuilder CommandBuilder = new SqlCommandBuilder(Adapter);
Adapter.UpdateCommand = CommandBuilder.GetUpdateCommand();
Adapter.InsertCommand = CommandBuilder.GetInsertCommand();
Adapter.DeleteCommand = CommandBuilder.GetDeleteCommand();
public void Guardar(DataTable Empleados)
{
// creamos un adapter para realizar la actualización
SqlDataAdapter Adapter = new SqlDataAdapter(“SELECT * FROM Empleados”, this.cn);
// usamos un command builder para configurar los comandos de actualización
SqlCommandBuilder CommandBuilder = new SqlCommandBuilder(Adapter);
Adapter.UpdateCommand = CommandBuilder.GetUpdateCommand();
Adapter.InsertCommand = CommandBuilder.GetInsertCommand();
Adapter.DeleteCommand = CommandBuilder.GetDeleteCommand();
// este comando nos sirve para refrescar un registro
SqlCommand Resync = new SqlCommand(“SELECT * From Empleados WHERE IdEmpleado=@IdEmpleado”, this.cn);
Resync.Parameters.Add(“@IdEmpleado”, SqlDbType.Int);
try

{
Adapter.Update(Empleados);
}
catch ( DBConcurrencyException ex )
{
// Nuestra respuesta a un conflicto va a ser refrescar el registro
Adapter.SelectCommand = Resync;
Resync.Parameters[“@IdEmpleado”].Value = ex.Row[“IdEmpleado”, DataRowVersion.Original];
// el método Fill buscará el registro en el DataTable
// por clave primaria (IdEmpleado) y lo “refrescará”
if ( Adapter.Fill(Empleados) == 0 )
// la causa del conflicto es que ha sido eliminado (Fill devuelve cero registros)
{
if ( ex.Row.RowState == DataRowState.Deleted )
{
// en este punto tenemos un conflicto de concurrencia
// al eliminar un registro porque ha sido eliminado.
// Eliminamos definitivamente el registro
ex.Row.AcceptChanges();
// ignoramos el conflicto y seguimos con la actualización
Guardar(Empleados);
}
else
{
// en este punto tenemos un conflicto de concurrencia
// al modificar un registro porque ha sido eliminado
// Eliminamos el registro
// y volvemos a lanzar la excepción
ex.Row.Delete();
ex.Row.AcceptChanges();

throw ex;
}
}
else
{
// la causa del conflicto es que ha sido modificado
// Si el conflicto ha sido al eliminar el registro
// Fill ya lo habrá “recuperado” y refrescado.
// Aparecerá el registro con el error
// Si el conflicto ha sido al modificar el registro
// Fill lo habrá “refrescado”. Y aparecerá el registro
// con el error
// sólo hay que volver a lanzar la excepción
throw ex;
}
}
}
Fuente 1. Ejemplo de gestión de conflictos de concurrencia
dotNetManía
<<
25
dnm.ado.net
<<