Sobre configuraciones redundantes

Ns, 2Ns, N+1 y 2(N+1) … Sobre configuraciones redundantes de UPS @ CENTRO DE DATOS NIXVAL

El proveedor 'Microsoft.ACE.OLEDB.12.0' no está registrado en el equipo local

Tengo una aplicación que lee datos de un Excel y me sucedió el siguiente error:

Se detectó System.InvalidOperationException
  Message=El proveedor 'Microsoft.ACE.OLEDB.12.0' no está registrado en el equipo local.
  Source=System.Data

Entre paréntesis, mi cadena de conexión a Excel es:

Code Snippet

1. <add name="AserewareExcelDataSource" connectionString="Provider=Microsoft.ACE.OLEDB.12.0;Data Source=FileName.xlsx;Persist Security Info=False;Extended Properties=&quot;Excel 12.0 Xml;HDR=YES;IMEX=1&quot;" providerName="System.Data.OleDb" />

Bueno después de buscar y encontrar este link, donde al parecer no existe un driver adecuado hice lo siguiente.

Mi máquina es de 64bits y tenía esto en el destino de la plataforma, lo que difiere de lo comentado el vínculo de referencia:

Lo cambié a “Any CPU” o bien “x64”:

Y listo,… funcionando perfectamente.

Imagino que instalé la versión de 64 bit del driver..que ya está.

Etiquetas de Technorati: OLEBD,Drivers,Excel,DataSources,Visual Studio 2010

Niveles de disponibilidad

Regularmente ando buscando esta información y no la tenía a la mano…

---

Entonces, ¿qué porcentaje de disponibilidad será el adecuado para una aplicación determinada? A continuación se incluyen algunas pautas:

Categoría	Número de errores anual	Tiempo de inactividad anual	Tiempo medio de reparación	Disponibilidad
No comercial	10	88 horas	10 horas	99.00%
Comercial	5	44 horas	8,8 horas	99.50%
Crítica para la empresa	4	8,5 horas	2,25 horas	99.90%
Crítica para una misión	4	1 hora	0,25 horas	99.99%

Nota Para realizar estos cálculos de disponibilidad se han utilizado 365,25 X 24 = 8.766 horas al año.

fuente: Microsoft MSDN

---

Tal y como se describe en el tema referente a la confiabilidad, se pueden producir errores en las aplicaciones por muchos motivos:

• Comprobación inadecuada
• Problemas relacionados con cambios en la administración
• Falta de control y análisis continuados
• Errores en las operaciones
• Código poco consistente
• Ausencia de procesos de diseño de software de calidad
• Interacción con aplicaciones o servicios externos
• Condiciones de funcionamiento distintas (cambios en el nivel de uso, sobrecargas máximas)
• Sucesos inusuales (errores de seguridad, desbordamientos en la difusión)
• Errores de hardware (discos, controladores, dispositivos de red, servidores, fuentes de alimentación, memoria, CPU).
• Problemas de entorno (red eléctrica, refrigeración, incendios, inundaciones, polvo, catástrofes naturales)

Alrededor de un 40 por ciento del tiempo de inactividad de las aplicaciones se debe a una comprobación inadecuada, a una administración de cambios y a la ausencia de un control continuo de los errores. Otro 40 por ciento se debe a errores operativos producidos por la ausencia de procedimientos rigurosos y a errores de copia de seguridad/restauración. La confiabilidad del hardware ha mejorado durante los últimos años que menos del 10 por ciento del tiempo de inactividad se debe a problemas de hardware. El 10 por ciento restante del tiempo de inactividad se debe a problemas de entorno y a problemas de otro tipo.

En términos generales, se puede decir que la disponibilidad es una medida de la frecuencia con la que se puede utilizar la aplicación. Para ser más exactos, la disponibilidad es un cálculo porcentual del tiempo en que la aplicación está realmente disponible para controlar las solicitudes de servicio en comparación con el tiempo de ejecución total disponible previsto. El cálculo formal de la disponibilidad incluye el tiempo de reparación, ya que una aplicación que se está reparando no está disponible.

En el cálculo de la disponibilidad se utilizan varias medidas:

Nombre	Acrónimo	Cálculo	Definición
Tiempo medio entre errores	MTBF	Horas / número de errores	Duración media de funcionamiento de la aplicación antes de que produzca errores.
Tiempo medio de recuperación	MTTR	Horas de reparación / número de errores	Tiempo medio necesario para reparar y restaurar el servicio después de que se produzca un error.

La fórmula de disponibilidad tiene esta forma:

Disponibilidad = (MTBF / (MTBF + MTTR)) X 100

Considere, por ejemplo, una aplicación concebida para que funcione continuamente. Pongamos un punto de control de 1.000 horas consecutivas, dos errores de una hora durante ese período darían lugar a una disponibilidad de ((1.000/2) / ((1.000/2) + 1)) X 100 = (500 / 501) X 100 = 0,998 X 100 = 99,8 %.

Una forma conocida de describir la disponibilidad es mediante los "nueves": los tres nueves de una disponibilidad de un 99,9%. No obstante, hay que tener en cuenta que las implicaciones de la medición por nueves a veces se malinterpretan. Es necesario realizar algunos cálculos para descubrir que tres nueves (disponibilidad de un 99,9%) representan aproximadamente 8,5 horas de interrupción de servicio en un solo año. El nivel inmediatamente superior, cuatro nueves (99,99%), representa alrededor de una hora de interrupción de servicio en un año. Cinco nueves (99,999%) representan sólo cinco minutos de interrupción al año.

fuente: Microsoft MSDN

Etiquetas de Technorati: Disponibilidad,Distribuidas

Silverlight. WebServices. WCF. Cross-Domain. clientaccesspolicy.xml

Bueno el famoso archivo “clientaccesspolicy.xml” debe colocarse en la raíz de su servidor web, no así en la raíz de un directorio virtual (configurado como aplicación) que usted haya creado.

Si usted tiene una aplicación en un directorio virtual llamado “miaplicación” tal como:

http://midominio/miaplicacion

entonces debe colocar el “clientaccesspolicy.xml” en la raíz:

http://midominio/clientaccesspolicy.xml

Este es el típico archivo predeterminado que permitiría el acceso desde cualquier dominio llamador (claro, esto siempre funcionaría en el supuesto de que sus servicios Web no tengan algún mecanismo de autentificación).

Code Snippet

1. <?xml version="1.0" encoding="utf-8" ?>
2. <access-policy>
3.   <cross-domain-access>
4.     <policy>
5.       <allow-from http-request-headers="SOAPAction">
6.         <domain uri="*"/>
7.       </allow-from>
8.       <grant-to>
9.         <resource path="/" include-subpaths="true"/>
10.       </grant-to>
11.     </policy>
12.   </cross-domain-access>
13. </access-policy>

En cualquier caso si los dominios desde los que se llama son simples alias o entradas en un DNS (CNAME or A records) que apuntan a la misma IP, la seguridad provista por el dominio de su aplicación funcionaría adecuadamente y estaría en el contexto de las llamadas, por lo tanto una llamada a su servicio desde “midominioalias1/miaplicacion/miservicio” o desde “midominioalias2/miaplicacion/miservicio” no debería tener problemas aún cuando haya protegido sus servicios con algún mecanismo de seguridad de acceso como el provisto por ASP.NET. Este otro tema de seguridad se puede ver en Servicios WCF y ASP.NET

Ahora bien para limitar el acceso a su servicio desde dominios conocidos los mejor será eliminar el permisivo “<domain uri="*"/>”  y colocar explícitamente sus dominios en su archivo “clientaccesspolicy.xml”.

En el ejemplo siguiente, con los asteriscos, se aceptan llamadas desde cualquier subdominio de “midominio” y de subdominios de algunos otros dominios específicos (que podrían también ser alias de su propio dominio en un DNS). Podría poner una URL específica que acepta explícitamente, quitando el asterisco y reemplazándolo por “www.midominioalias1.com”.

Code Snippet

1. <?xml version="1.0" encoding="utf-8" ?>
2. <access-policy>
3.   <cross-domain-access>
4.     <policy>
5.       <allow-from http-request-headers="SOAPAction">
6.         <!--<domain uri="*"/>-->
7.         <domain uri="http://midominio.com" />
8.         <domain uri="http://*.midominio.com" />
9.         <domain uri="http://*.midominioalias1.com" />
10.         <domain uri="http://*.midominio2.com" />
11.       </allow-from>
12.       <grant-to>
13.         <resource path="/" include-subpaths="true"/>
14.       </grant-to>
15.     </policy>
16.   </cross-domain-access>
17. </access-policy>

Dado que este archivo reside en la raíz de su sitio web, tal como está el “path” significa que podría llamar a cualquier servicio web que esté ubicado donde quiera bajo este punto de partida. Si necesita limitar el acceso a cierta ubicación debe colocar el “path”, por ejemplo: “path=”/miaplicacion/misservicios”. Vea Restricciones de seguridad de acceso a redes en Silverlight

Etiquetas de Technorati: Silverlight,WCF,WebServices,CrossDomain

No olvidar El mensaje "Código de error: 0x80070002" cita un problema en la comprobación de la licencia después de una actualización en un equipo Dell

[Window Title]
Copias de seguridad de Windows: opciones para solucionar problemas

[Main Instruction]
Comprobar copia de seguridad

[Content]
El sistema no puede encontrar el archivo especificado.


[V] Mostrar detalles [Intentar ejecutar de nuevo la copia de seguridad] [Cambiar configuración de copia de seguridad] [Cancelar]

[Expanded Information]
Hora de copia de seguridad: 04/02/2011 06:28 p.m.
Ubicación de copia de seguridad: Backup (J:)
Código de error:0x80070002


El mensaje "Código de error: 0x80070002" cita un problema en la comprobación de la licencia después de una actualización en un equipo Dell

Interop COM Exception

Introducción

Tengo una aplicación desarrollada para el NET Framework 3.5 SP1 y la he publicado en mi IIS local.

Contexto

Windows 7 64 bits, SQL Server Express 2008 R2, IIS 7

Solución

1. Permitir 32 bit.

1. Autorizar al usuario IUSR en la carpeta donde se encuentre registrado el componente COM.

1. Autorizar al usuario en la base de datos.

 

Contexto

Windows Server 2008 Estándar de 32bit

Problema

Retrieving the COM class factory for component with CLSID {E95C0FB5-A09E-46F6-9CB3-ADD6B866A38A} failed due to the following error: 80040154.

System.Runtime.InteropServices.COMException: Retrieving the COM class factory for component with CLSID {E95C0FB5-A09E-46F6-9CB3-ADD6B866A38A} failed due to the following error: 80040154

Solución

Simplemente registrar el componente con regsvr32. Si no conoce qué componente es busque el GUID con regedit.

Error al instanciar MS Outlook Application desde un complemento de MS Project

Durante el desarrollo de un complemento (Addin) para MS Project que se conecta con Outlook me encontré el siguiente error COM al intentar crear el objeto Application de Outlook:

Código

using MSOutlook = Microsoft.Office.Interop.Outlook;
...
MSOutlook.Application outlook = new  MSOutlook.Application();

Excepción (Exception)

Error al recuperar un generador de clases COM para el componente con CLSID {0006F03A-0000-0000-C000-000000000046} debido al siguiente error: 80080005.

La solución

Aunque tediosa por lo lenta, fue reparar la instalación de Visual Studio Tools for Office y de Office (en mi caso versiones 2010) desde el panel de control.








Lamentablemente no hice la reparación en partes, por lo que no supe si sólo con una de las dos reparaciones se corrige el problema. Dejo un voto para la reparación de Office.

Etiquetas de Technorati: Complemento,Addin,Office,Project,Outlook,NET Framework

---(Fin)---