The section can't be defined in this configuration file (the allowed definition context is 'MachineToApplication')

La verdad que este error si me a quitado el sueño no solo una vez, sino en repetidas ocasiones, la primera vez si que dure mucho tiempo para buscarle una solucion pero no fue de mi agrado, las otras ocasiones descubri otras variantes para solucionar el error, hoy me volvi a tocar con lo mismo y me anime a escribir un poco de aquello.

Primero entendamos y conoscamos el error a fondo y despues hablemos de soluciones posibles:

Cuando tenemos una aplicacion que deseamos usar el membership, por lo tanto roles tambien, al probarla en nuestro ambiente de Mono, es posible que obtengamos este error:

The section can't be defined in this configuration file (the allowed definition context is 'MachineToApplication')

Verlo a primer encontronazo, nos quedamos perplejos, un error muy extraño que no nos dice mucho, solo que la definicion del roleManager no se puede declarar en el webconfig, sino en otro contexto, pero sucede que nuestra aplicacion trabaja bien en nuestro ambiente de windows, en el caso de que sea que estemos portandolo desde alli. Pues googleando un poco no encontramos absolutamente nada que nos ayude, un error poco discutido, incluso solo vi algunos que suguieren que actualizemos a una version mas nueva de mono si hay alguna... esta solucion me parece a la que dan algunos soportes tecnicos a los usuarios cuando tienen cualquier tipo de problema que sin saber mucho la situacion solo dicen "resetea el computador, si persiste llamame, adios". Obviamente esta no es la solucion, ya que he visto el mismo error en versiones diferentes de mono.

El problema radica en que el mod_mono no esta viendo nuestra aplicacion como una real aplicacion, sino como una carpeta comun. Este error ocurre si no tenemos configurada (o no lo esta correctamente) nuestra aplicacion en el mod_mono.conf o si estamos trabajando con el AutoHosting.

Si configuramos nuestra aplicacion manualmente en el mod_mono.conf no veremos mas este error y todas las aplicaciones que hostiemos la debemos de configurar correctamente alli, aconsejable utilizar esta utilidad que nos genera la configuracion correcta para nuestra aplicacion http://go-mono.com/config-mod-mono/

Otra forma de resolver el error sin enliarnos mucho con la configuracion es copiar nuestra aplicacion en el root de nuestro site, es decir, fuera de cualquier carpeta, con el solo hecho de escribir http://midominio.com esta entre inmediatamente. Esta solucion es viable si no pensamos hostear ninguna otra aplicacion mas, solo una.

Pero que sucede si deseo utilizar el AutoHosting y estoy recibiendo este error?

El autohosting permite que tengamos muchas aplicaciones en un mismo dominio separados por carperas y que estas no sean necesarias ser configuradas en ningun archivo de configuracion, definitivamente el autohosting es la mejor opcion para trabajar, pero este error nos hace la vida imposible ya que si tenemos 10 aplicaciones hosteadas y una sola de estas utilizara el membership y nos arroja este error, pues nuestras otras 9 aplicaciones se bloquean!!

Por que el AutoHosting no reconoce nuestra aplicacion como tal??? pues lo que sucede es que el autohosting para considerar que una carpeta es una aplicacion solo toma en cuenta si existe un archivo "Global.asax" o una carpeta "bin". Asi que si no tenemos ninguno de los dos, pues a crearlo... Pero por su puesto que tengo por lo menos la carpeta "Bin" en mi aplicacion y sigue presentando el error.... dije "Bin" con la B en mayuscula? pues ahi esta el problema, el autohosting es CASE-SENSITIVE, el esta buscando un "bin" no un "Bin".

WebForms vs MVC

Recuerdo que en el año 2003 cuando el bum del Framework.Net de microsoft se hacia fuertemente popular donde ellos planteaban un nuevo paradigma de construcción de paginas web mucho "mas fácil" que los métodos convencionales conocidos, pues yo me resistía al cambio ya que desde que comencé a investigar su funcionamiento, me daba cuenta que el control de lo que se construía no me pertenecía, estabas atado a lo que el framework quisiera hacer por ti, también me preguntaba en donde iba a dejar mi tan amado JavaScript (JS), como iba a administrar los controles de los formularios sin una integración realmente adecuada con el JS y eso de estar posteando al servidor para que los eventos se disparasen y otras acciones se realizaran en una misma pagina, el viewstate que reentilizaba considerablemente las cargas de las paginas, pues todo me parecia muy mal visto por mi, siempre fui un programador fuerte de lo convencional ASP 3.0 (el clasico) y PHP, construía a mano todos mis recursos de JS, mis clases para mis aplicaciones, un total dominio de los tags de HTML... en fin, mi cambio al .Net no fue de mi agrado pero tuve que hacerlo.

En la curva del aprendizaje y la experiencia del día a día, me enamore de C#, una riqueza inmensa e incomparable en un lenguaje de programación que no le tiene que envidiar nada a ninguno, sin lugar a dudas mi favorito entre muchos que conozco y en mi opinión personal diría que es el mejor.

La ventaja inmediata a la creación de los WebForms era la gran rapidez de desarrollo, la facilidad de hacer cosas que me tomaban horas y días de hacer antes lo hacia en un santiamén, quizás no tenia el control total de lo que hacia pero mi productividad se disparo por los cielos. El no tener el control total de lo que hacia ya no me quitaba el sueño porque no me impedía construir aplicaciones a mis gustos y sin dificultad, pues el resultado de los proyectos siempre era el deseado y de calidad. También con la experiencia se aprendían trucos para realizar algunas acciones que pensábamos que no eran posible sin tener "dicho control", pero la verdad es que "casi" todo era posible, solo era asunto de ingeniársela y buscarle la vuelta. Microsoft siempre abogo y defendió haber tenido el mejor framework y herramienta para el desarrollo web con los WebForms y al final de la historia le di la razón.

Al pasar los años comencé a oír mucho de los framework MVC existentes en otras plataformas y de sus grandes ventajas, también al parecer muchos desarrolladores de Microsoft siempre se quedaron con la queja que yo tuve desde un inicio como la falta de control y otros aspectos negativos que siempre estuvieron latentes en los WebForms como la lentitud de la carga de las aplicaciones por el complejo ciclo de vida de una pagina , la falta de trabajar en un contexto real para entorno web ya que el concepto de los WebForms era como simular el desarrollo como si se tratase de aplicaciones WinForm, etc. Por lo tanto, el paradigma MVC proponía una solución a todas estas cuestiones, por lo cual Microsoft se embarco a lanzar su primer MVC soportado por su Framework.Net y con el tiempo ha seguido evolucionando a un producto mas acabado y pulido por ellos.

Ahora la pregunta del millón es: debo de cambiar a este nuevo concepto de desarrollo web? lo que se me vendió como "lo ultimo y mejor" por muchos años para desarrollo web ya no lo es, y me lo quieren reemplazar por algo que ya existía en otras plataformas y ahora me quieren decir que es mejor? debo llorar o reír?

Pues me tomare la libertad de responderme a mi mismo tomando como inicio un solo punto: los WebForms no han sido reemplazados ni descontinuados por Microsoft, por lo tanto el MVC solo representa una opcion diferente para el desarrollo de aplicaciones Web para atraer a una comunidad grande que apoya y trabaja sobre este patrón y para satisfacer las necesidades de un sector que aclamaba algo diferente.

El modelo que propone el MVC esta mejor conceptualizado para contruir aplicaciones Web que los WebForms, es cierto, pero por esto no lo considero la panacea. Cuando veo la capa de las vistas de la pagina, en donde tengo que volver a recurrir a mi programacion "espaguettis", donde tengo que unir el HTML con el codigo fuente de la aplicacion para mapear mis variables, imprimir mis resultado, construir mis JS o utilizar un framework de ajax, pues siento que estoy volviendo al pasado otra vez en donde ahora solo se me obliga a separar mis tareas en diferentes lugares (lo que complica un poco el asunto si no estamos familiarizados con los MVC): ponme la lógica en este folder, ponme la base de datos aqui y despues has todo lo que quieras en esta pagina, tags de HTML, tags de programacion, javascript (si son necesarios), estilos, etc. En donde queda el RAD (Rapid Application Development) que me ofrece los WebForms? en donde queda mi multitudes de controles de servidor que hacen todo el trabajo pesado por mi? sacrificare mi productividad, mi rapidez en desarrollo, mi comodidad que me he venido acostumbrando y ganando durante todos estos años para volver a lo que tenia en el pasado y ya lo había dejado atrás... "el control".

Lo de volver al pasado lo digo en forma literal ya que en el MVC seguiremos contando con el rico lenguaje C#, los recursos del framework.Net y muchas otras librerías mas que siempre han estado a nuestra disposición en esta plataforma.

En resumen, no pongo en duda la superioridad del MVC para el desarrollo Web, pero tampoco le quito méritos a los WebForms con todo y sus defectos, seguirá siendo la mejor opción RAD y se seguirán haciendo aplicaciones robustas y estables como lo hemos estado haciendo por años, simplemente sera un asunto de preferencia utilizar uno u el otro y en algunos casos dependerá del proyecto que desearemos embarcarnos.

Por lo menos si aconsejo que las personas que nunca habían conocido ningún lenguage de desarrollo web lo empiecen hacer desde el MVC porque solo así se puede conocer bien el funcionamiento y el mecanismo de las paginas Web en un contexto real. Luego utilizar los WebForms para sacar sus propias conclusiones, aunque este ultimo es mas fácil de aprender de entrada por su similitud al desarrollo de aplicaciones WinForms.

FreeBSD, Mono y FireBird .Net Provider

Al intentar correr un programa C# compilado en windows, el cual usa el .Net Provider para Firebird me arrojo el siguiente error:

When the FbConnection.Open() method was called, one exception was raised:

Unhandled Exception: System.TypeInitializationException: An exception was
thrown by the type initializer for FirebirdSql.Data.Common.Charset --->
System.ArgumentException: Encoding name 'shift_jis' not supported
Parameter name: name
at System.Text.Encoding.GetEncoding (System.String name) [0x00000]
at FirebirdSql.Data.Common.Charset.GetEncoding () [0x00000]
at FirebirdSql.Data.Common.Charset..ctor (Int32 id, System.String name,
Int32 bytesPerCharacter, System.String systemName) [0x00000]
at FirebirdSql.Data.Common.Charset.InitializeSupportedCharsets ()
[0x00000]


Esto se debe a que la dll del Provider de Firebird (FirebirdSql.Data.FirebirdClient.dll)
fue compilada con el Framework .Net de Windows y por lo tanto encapsula una serie de
CharSet que no existe en nuestro sistema operativo, no solo en FreeBSD, sino
tambien cualquier OS unix. Por suerte en la pagina oficial de FireBird estan dos
versiones de esta dll, una para .Net Windows, otra para Mono. Con esta desaparece el
error* pero me trae uno nuevo:

Unhandled Exception: System.ArgumentOutOfRangeException: Index is less than 0 or more than or equal to the list count.
Parameter name: index
0
at System.Collections.ArrayList.ThrowNewArgumentOutOfRangeException (System.String name, System.Object actual,
System.String message) [0x00000] in :0
at System.Collections.ArrayList.get_Item (Int32 index) [0x00000] in :0
at System.Diagnostics.ProcessModuleCollection.get_Item (Int32 index) [0x00000] in :0
at System.Diagnostics.Process.get_MainModule () [0x00000] in :0
at (wrapper remoting-invoke-with-check) System.Diagnostics.Process:get_MainModule ()
at FirebirdSql.Data.FirebirdClient.FbConnectionInternal.GetProcessName () [0x00000] in :0


En un sistema operativo basado en Linux nunca lo veremos este error, ya que las
funciones encapsuladas en el System.Diagnostics.Process hace un llamado a un
recurso propio del OS: "/PROC"

En FreeBSD no viene habilitado por defecto a diferencia de Linux, asi que lo debemos
de activar agregando la siguiente lineas en el /etc/fstab :
proc /proc procfs rw 0 0

Luego de reiniciar el sistema estara activado. Pero si no deseamos esperar a
reiniciar el sistema, pues montamos el proc directamente:

mount -t procfs proc /proc

Nuevamente probamos nuestro programa y funciona !

*Nota: para los que le sirva la informacion, en Ubuntu 10 no me funciono el .Net Provider de Firebird para Mono,
ya que me dio otro mensaje de error buscando otro CharSet diferente (EUC-JP),
en este caso la solucion es un poco mas trabajosa, intentar de activar/registrar este
charSet en Ubuntu o compilar los fuentes del .Net Provider en Ubuntu y utilizar la dll generada, esta ultima opcion fue la que yo tome para resolver el error.

Que cosas no puede hacer Firebird?

Entre las primeras cosas que un experto de una particular base de datos se debe preocupar, son sus limitaciones, es decir, hasta donde puede llegar la misma.

Obviamente Firebird tiene sus excepciones también, las cuales debemos de conocer bien al momento de embarcarnos en un proyecto.

Firebird es una base de datos que no tiene de que envidiarle mucho a otras, es "casi perfecta", pero no quiero hablar de sus cualidades sino de sus carencias en este post, pero a decir verdad no tiene mucha cola que pisarle.

En sentido general, las mas populares e importantes base de datos del mercado siempre carecen de una que otra cosa que quizas no sean del todo determinantes, pero entre este grupo de base de datos "elite", digase MS SQL Server, Oracle, DB2, PosgreSQL y MySQL (aunque no me gustaria agregar a la lista esta ultima), Firebird carece de dos grandes prestaciones que son vitales en ambientes corporativos y/o críticos que nunca podrian faltar:

- Conexiones seguras: se crean para que nuestras aplicaciones transmitan su informacion cifradas (encriptadas), despreocupándonos del temor que intrusos puedan interceptar nuestra informacion por la red para su provecho ya que no podrían descifrar los datos capturados.

- Clustering: es determinante para tener una "alta disponibilidad" en nuestros sistemas críticos.

La pregunta seria: nuestros proyectos podrían ser viables sin estas dos características "casi" elementales en entornos donde la seguridad y la disponibilidad son las prioridades principales?

Lamentablemente el tema del clustering quizas sera un apartado que los desarrolladores de FireBird nunca tocaran, ya que uno de los propósitos fundamentales del proyecto FireBird es de disponer de una base de datos libre de mantenimiento y de facil uso. Las implicaciones de tener un servicio de base de datos sobre un cluster lo hace una tarea ardua de llevar a cabo (configuración, instalación, monitoreo, etc.). El tema de las conexiones seguras si se podría abordar en un futuro, pero por los momentos no tenemos noticia de eso.

Instalar Firebird 2.1.3 en FreeBSD 8

La ultima versión de Firebird en la lista de los ports de Freebsd8 es la 2.0.3, sin embargo la ultima versión estable de firebird liberada es la 2.1.3 ya hace casi un año. La verdad es que no entiendo porque han tardado tanto en portar esta ultima versión y quizas no lo hagan por mucho mas tiempo, pero no puedo seguir esperando para poderla utilizar.

Teóricamente utilizando los fuentes de la ultima versión de firebird puedo compilarlo en FreeBSD asi que vamos a obra:

Necesitamos descargar e instalar todas las dependencias de Firebird manualmente, pero cuales son estas? pues las dependencias de la versión 2.0.3 son las mismas que la 2.1.5, asi que solo visualizamos el paquete de la 2.0.3:

B-deps: autoconf-2.62 autoconf-wrapper-20071109 automake-1.9.6_3 automake-wrapper-20071109 bison-2.4.1,1 gettext-0.17_1 gmake-3.81_3 icu-3.8.1_2 libiconv-1.13.1 libtool-2.2.6a m4-1.4.13,1 perl-5.8.9_3 R-deps: icu-3.8.1_2

Si ya tenemos el servidor 2.0.3 instalado con anterioridad, pues nos ahorramos esto, solo desintalamos el servidor y el cliente con pkg_delete

Descargamos el código fuente de la versión 2.1.3 a nuestro equipo, este viene empaquetado en formato tar.bz2

Una vez descomprimido en nuestro equipo comenzamos a instalar: make && make install && make clean

Nuestro primer error:

Error expanding embedded variable.

Esto se debe a que debemos compilar los fuentes con: gmake && gmake install.

Siguiente error:

vi.c:919:74: error: macro "__weak_reference" requires 2 arguments, but only 1 given vi.c: In function 'get_alias_text': vi.c:919: error: expected declaration specifiers before '__weak_reference' vi.c:924: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token vi.c:954: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token vi.c:999: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token vi.c:1055: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token vi.c:1104: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token vi.c:919: error: parameter name omitted vi.c:1125: error: expected '{' at end of input ...
`/usr/home/martin/downloads/Firebird-2.1.2.18118-0/extern/editline/src' gmake[4]: *** [all-recursive] Error 1 gmake[4]: Leaving directory `/usr/home/martin/downloads/Firebird-2.1.2.18118-0/extern/editline' gmake[3]: *** [all] Error 2 gmake[3]: Leaving directory `/usr/home/martin/downloads/Firebird-2.1.2.18118-0/extern/editline'

En este punto debemos de compilar el firebird sin utilizar esta librería "editline", al parecer no funciona bien FreeBSD.

./configure --without-editline
gmake
gmake install

Siguiente error:

mkdir: /usr/local/firebird/UDF: File exists find: ./firebird/examples/v5: No such file or directory Example files have not been built! chmod: examples/*.fdb: No such file or directory gmake[2]: Leaving directory `/usr/home/erick/Firebird-2.1.3.18185-0/gen'

Realmente no es un error, simplemente son los últimos mensajes que aparecen después de la instalación lo cual no me convence, es como si terminara a medias. Revisando el script que realiza la instalación "install.sh" señala que ciertamente esto es todo!

Los mensajes que presenta de que no pudo encontrar algunos archivos, realmente no es nada importante ya que se trata algunos archivos de ejemplos, asi que procedo a probar mi servidor después de recargar los servicios inetd.

Intentando conectarme desde una aplicación remota no logro establecer la conexion sin obtener algun mensaje de error claro. En el mismo servidor Freebsd verifico si el puerto 3050 de firebird esta escuchando con el comando "sockstat" y todo esta en su lugar. Proceso a utilizar el isql y desde que intento de ejecutar el comando veo el siguiente mensaje de error:

/libexec/ld-elf.so.1: Shared object "libicuuc.so.30" not found, required by "libfbembed.so.2.1"

Al parecer algunas librerías no se copiaron en donde deberían de estar en el proceso de instalación, asi que lo hago manual ya que todas ellas se encuentran en el firebird compilado.

Dentro de la carpeta de los fuentes se crea una carpeta nueva llamada "gen", aqui se deposita el binario del servidor, dentro de la carpeta "lib" estan nuestros archivos, procedemos a copiarlos en las rutas que son necesitados:
cp -v libicu* /libexec/ cp -v libicu* /usr/local/firebird/lib

Volvemos a probar isql y este accede sin problemas, ahora tratare de conectar mi aplicación externa a mi nuevo servidor y se produce un nuevo mensaje de error:

CHARACTER SET ISO8859_1 is not installed.

En caso de que nuestra aplicación y base de datos no este usando ningun "character set", probablemente no surgiría ningún mensaje de error.

Los diferentes character set estan registrados en un archivo llamado fbintl.conf, al revisar mi instalacion dicho archivo no existe, pero si esta en el compilado, entramos al forder gen/firebird/intl procedemos a copiarlo:

cp -v fbintl.conf /usr/local/firebird/intl

Nuevamente entro a mi aplicación externa y pruebo... pasa la prueba ! hago algunas inserciones, modificaciones y consultas complejas, todo en orden :)

Sin poseer la instalación portable oficial para FreeBSD se hace muy tedioso el aventurarnos a instalar un paquete por medio de los código fuentes, ya que nos pueden mostrar un sin fin de inconvenientes en el proceso.

Cual es el mejor servicio webhosting en la internet?

Hace algunos años atrás buscaba un buen servicio de hosting compartido para alojar unos pocos proyectos, deseaba buenas prestaciones (features) y aceptable precio, busque mucho por la internet y la verdad que me encontré con todo un mundo de publicidad de empresas que ofrecen hosting, muchas tentativas y otras no tanto, una situación muy difícil de elegir entre tantas jugosas opciones.

Entre todas las posibles empresas de webhosting del momento habían tres que ofrecían las más tentativas prestaciones, y me decidí por una de ella ya que esta mostraba casualmente un cuadro de comparación de ventajas con relación a sus más cercanos competidores y definitivamente era la que ofrecía más a casi el mismo precio: IXWEBHOSTING.COM

Espacio ilimitado en disco !!!
Trafico de ancho de banda ilimitado !!!
Alojamientos de dominios ilimitados !!!
IP publicas asignadas !!!
Registro de dominios gratis !!!

Sobre todo quería contratar un paquete Windows que son más caros que los convencionales (Linux)... después de dos años el resultado fue catastrófico! Cometí un error de principiantes, me deje llevar de un espejismo que ofrecía todo a menor costo, pero lo barato sale caro.

El problema de IXwebhosting al igual que otras compañías de hospedaje del mismo calibre, es que ofrecen tantas maravillas a un precio tan accesible y poseen una agresiva publicidad que les favorece en la internet, lo que trae como resultado una superpoblación en sus servidores de servicio compartido, esto causa que tengamos fluctuaciones constantes en el servicio, como la pagina no responde en momentos determinados, cargas demasiadas lentas por presentar cualquier pagina hosteada, gran lag de respuesta, sobre todo en páginas con conexión a base de datos. Recuerdo que cuando me conectaba al sqlmanager del ms-sqlserver, podía ver la lista completa de todas las base de datos que tenía el servidor en cuestión, habían centenares y centenares de base de datos, esto me ponía los pelos de punta, para hacer un backup de una base de datos de 100mb dure casi una hora.

Esta experiencia me ayudo a madurar al momento de seleccionar un hosting:

1. No dejarnos llevar por las prestaciones y la economía, la mayoría que ofrecen "mucho" lo dan a menor calidad
2. Cuando tengamos una posible empresa que deseemos contratar sus servicios, debemos visitar websites que se dedican a valorar y posicionar las compañías de hospedaje, algunos no son objetivos, pero la mayoría sí. Busquemos siempre los website con review de los clientes y detengamosno a leerlos. Solo tenemos que escribir en google "hosting reviews"
3. Por lo general los mejores servicios provienen de compañía de hospedaje que ofrecen limitaciones reales en sus prestaciones.
4. No contratar servicios de revendedores, irnos directamente con la empresa que provee el servicio. Los revendedores por lo general contratan los servicios más económicos de las empresas de hospedaje saturadas
5. Contratar servicios de empresas norteamericanas para los que vivimos en occidente (continente americano y Europa occidental). Los estándares de calidad del servicio son más exigente allí, precios más razonables, personal técnico mas capacitados, lag de respuesta en sus servidores menores y un etcétera de beneficios que casi ningún país se le puede igualar.

Basado en mis investigaciones, experiencia personal y de conocidos no recomiendo los siguientes website:

ixwebhosting
iweb
godaddy
yahoo
mihosting
bluehosting
lunarpages
dreamhost

Y me gustaría mencionar una larga lista de hosting muy populares con supuestos servicios ilimitados de disco, tráfico y otros menesteres mas. Aunque algunos pocos tengan una buena crítica, podemos caer en la mala suerte de estar en uno de sus servidores sobrepoblados o tener problemas con una pronta respuesta de soporte. Entre estas compañías de hospedaje de "ilimitadas prestaciones" me gustaría solo sacar una que al parecer es la mejorcita hostgator.com

Debemos estar claro que este marketing de "Ilimitadas prestaciones" no son reales, todo tiene su límite, sencillamente saben que más del 90% de sus clientes nunca almacenaran más de 500 megas entre pagina web y base de datos, el real problema para estas compañías es la carga de CPU, ya que el acceso dinámico a base de datos y una considerable cantidad de visitas de muchos website simultáneos en un mismo equipo trae como consecuencia un alto consumo de recursos que relentiza todas las operaciones. Muchas veces estas compañías sacan de circulacion algunos website con la excusa de "no están bien programados / desarrollados" porque generan un consumo excesivo de recursos, recomiendan a los dueños de los mismos a que reformulen su website o contraten un servicio superior como por ejemplo un "servidor dedicado".

Existen muchas personas que prefieren contratar hosting locales, es decir, en su pais de origen, pero nunca he compartido esta opinion por algunos motivos:

1. Muchos son revendedores
2. Soporte mediocre
3. Pocas prestaciones
4. Generalmente los precios de las companias locales duplican y triplican a los precios reales norteamericanos, ya que los costos de los servicios locales para mantener un servidor activo con una conectividad al internet de altas prestaciones 24/7 son muchos mas elevados y en algunos casos los precios son "abusivos"

En este ultimo punto me gustaria exponer un "descarado" caso en mi pais, La compañia mas grande de telecomunicaciones local de nombre "Codetel", entre su amplio paquete de servicios ofrece tambien alojamiento web, pero las prestaciones y el precio que tienen me parece una falta de respeto total a mi inteligencia y la de cualquier ser humano que trabaja en este medio tecnologico. Veamos, de su propia pagina oficial extraigo los siguientes datos:

Servidor dedicado:
1 ip fija
80gb de disco "SATA"
1gb de memoria ram
Trafico ilimitado (por lo menos algo bueno)
100 cuentas de correos de maximo 100mb cada una
SQL Server - 2GB de datos y capacidad para crear 100 base de datos
Windows 2003 server

Aunque no señalan el tipo de equipo que es el servidor, dedusco que por tener un disco SATA y no SCSI, con tan solo 1gb de memoria, con una version vieja de SQL Server, no se trata de un equipo nada moderno y rapido, ni si quiera de un servidor serio, creo que cualquier computador casero se mete en los bolsillos a este "servidor".

Precio: para contratar el servicio hay que pagar una "activacion" por un costo de 340 dolares, y una renta mensual de 340 dolares, asi que el primer año con nuestro servicio sera de 4420 dolares !!! es acaso un chiste?

Ahora veamos el alojamiento compartido "shared hosting" que tienen:

Espacio en disco 250mb (basico) y 500mb (empresarial) !!!
Cuentas de correo 20 (basico) y 60 (empresarial) de 10mb cada una
windows 2003 server
SQL Server no tiene para ningun plan, pero el plan empresarial puede contratar el servicio de modo opcional

Precios: pago por activacion 23 dolares (para ambos planes), renta mensual de 18.5 dolares plan basico y 23 dolares plan empresarial. Nuestro primer año de servicio costara 245 dolares (basico) y 300 dolares (empresarial). Si queremos añadir soporte de base de datos al plan empresarial debemos pagar pero no esta claro cuanto dinero mas, pero estoy seguro que no es poco. Creo que solo con el pirrico espacio en disco y el precio anual que se debe pagar es un descaro de los mas vil.

Todo esto sin mencionar que a presar de ser la compañia mas grande de telecomunicaciones del pais es la que mas fluctua con el servicio de internet, incluso las caidas de este servicio han estado varias veces presente en la prensa local como noticia, por lo tanto no creo que tengamos garantizado una disponibilidad de 24/7/365 de nuestro hospedaje contratado con ellos.

Consultas frizadas / colgadas en Firebird 2.1

La verdad que este es un suceso lo he visto en repetidas ocasiones, lanzo una simple o compleja consulta SQL que con anterioridad he lanzado obteniendo los resultados deseados, pero un dia la misma consulta se cuelga en un limbo interminable. Que sucede? no he realizado ningun cambio de estructura en las tablas en cuestion, quizas existen mas registros que otros dias, pero no sera este el motivo?... Por supuesto que no... El problema es "corrupción en la base de datos" !!!

Por lo general existe una tabla corrupta para ser especifico, haciendo una simple consulta y recorriendo todos los registros de cada una de las tablas en cuestion, daremos con una que no permitira recorrer todos los registros, quedándose colgada.

La unica solucion a este problema por suerte es la mas sencilla de todas, hacer un backup / restore de la base de datos. Todavia no me he topado con el caso que me lleve a soluciones mas extremas.

Como observación, he visto que este tipo de corrupción mayormente aparece cuando intento de insertar cantidades masivas de registros a múltiples tablas.