Hace algun tiempo un administrador de proyectos que tenia le conuslto a Don Fernando Diez, Filólogo del periodico LA NACION sobre el uso de la palabra interfaz. He aqui su respuesta:
INTERFAZ.
La voz inglesa interface, que significa, en informática, ‘conexión física y funcional entre dos aparatos o sistemas independientes’, se ha adaptado al español en la forma INTERFAZ: «Su interfaz gráfica y capacidades de acceso a Internet facilitarán aún más el uso del PC» (Vanguardia [Esp.] 30.8.95).
Su plural es INTERFACES (→ plural, 1g). Aunque no es infrecuente su uso en masculino, debe emplearse en FEMENINO, ya que esta palabra incluye en su forma el sustantivo femenino FAZ.
Con este sentido, NO debe usarse la forma interfase, que no responde ni a la pronunciación ni a la estructura semántica del étimo inglés, que se ha formado con el sustantivo face, cuyo equivalente español es FAZ, no fase. Tampoco se aconseja usar con este significado el término interficie.
Aparte les dejo un par de definiciones de la RAE con respecto a este tema:
interfaz:
(Del ingl. interface, superficie de contacto).
1. f. Inform. Conexión física y funcional entre dos aparatos o sistemas independientes.
interfase:
1. f. Biol. Período del ciclo celular en el que tiene lugar la síntesis de proteínas y la replicación del material genético.
2. f. Fís. y Quím. Superficie de separación entre dos fases.
Así que, como ven, esta claro: únicamente debe usarse interfaz e interfaces en nuestros quehaceres informáticos.
26 ene 2010
7 ene 2010
Uno de viejitos
Hace unos días, me asignaron a un proyecto de un cliente que tiene su base de Datos en SQL Server 2000 la cual tenia bastante tiempo de no travesear. Una de las cosas que tenia que atender era habilitar el control de errores de un store procedure que ya existía y bitacorearlos en otra tabla a modo de monitor.
Como alguien dijo alguna vez: "¡No se haga la barba en seco!" refiriéndose a lo doloroso que eso podía llegar a ser. El manejo de errores (asumiendo que se le pueda llamar asi) es increíblemente engorroso, problemático e inflexible (fui generoso en los adjetivos).
Empecemos mi queja: resulta que la variable @@ERROR que es lo único que tenemos para determinar errores en SQL Server 2000 (Ni siquiera piensen en estructuras tipo Try Cacth), solo se puede capturar inmediatamente despues de la sentencia que produce el error. Osea si tenemos algo como esto:
Increible ¿cierto?
Foy: Ahora, y el mensaje del error ¿como lo capturamos para guardarlo?
SQLServer 2000: ¿Mensaje de error? ¿Que es eso?
Así es, no hay manera de capturar el mensaje de error o como decía un articulo al respecto: "There is no supported way to retrieve the full text of an error message in SQL 2000". Bueno en realidad se supone que si hay una manera, en este articulo se explica que haciendo uso de un store procedure de sistema (xp_readerrorlog) se puede, sin embargo se requiere tener acceso al mismo siendo owner de la base de datos, a mi particularmente no me sirve esta solución (ademas no tuve oportunidad de probar esta solución por eso señalo "se supone que funciona").
En vista de esto no quedo más remedio que usar algo como esto:
La otra opción es escribir mensajes de error personalizados dependiendo del numero de error pero llegado ha este punto ya estaba cansado de las peripecias que habia tenido que hacer. por lo que me quede con el mensaje sin reemplazar tags. Si alguien sabe alguna forma de hacerlo muy bienvenida será, siempre que la recomiendacion no se sea ¿Por que no migras a 2005?...
Como alguien dijo alguna vez: "¡No se haga la barba en seco!" refiriéndose a lo doloroso que eso podía llegar a ser. El manejo de errores (asumiendo que se le pueda llamar asi) es increíblemente engorroso, problemático e inflexible (fui generoso en los adjetivos).
Empecemos mi queja: resulta que la variable @@ERROR que es lo único que tenemos para determinar errores en SQL Server 2000 (Ni siquiera piensen en estructuras tipo Try Cacth), solo se puede capturar inmediatamente despues de la sentencia que produce el error. Osea si tenemos algo como esto:
y quisiéramos guardar en una tabla de bitácora, si se produce un error, cualquiera que fuese: por ejemplo que en el INSERT no se pudo ejecutar por problemas de llaves primarias, o que el UPDATE no se pudo ejecutar por problema de llave foráneas o que se dio una división por cero en la operación matemática; tendríamos que hacer algo mas o menos asi:
...
WHILE algunacondicion
...
BEGIN
BEGIN TRANSACTION
INSERT INTO miTabla1 (campo1, campo2) VALUES (@parametro1, @parametro2)
UPDATE miTabla2 SET campo3 = @parametro3 WHERE campo4 = @parametro4
@variable1 = @varaible2 / @variable3
COMMIT TRANSACTION
...
END
...
Luego del tag logError deberíamos tener las sentencias para el tratamiento de errores así como otros "GOTO" para seguir con la ejecución del store procedure.
...
WHILE algunacondicion
BEGIN
....
BEGIN TRANSACTION
INSERT INTO miTabla1 (campo1, campo2) VALUES (@parametro1, @parametro2)
IF @@ERROR <> 0
BEGIN
GOTO logError
END
UPDATE miTabla2 SET campo3 = @parametro3 WHERE campo4 =@parametro4
IF @@ERROR <> 0
BEGIN
GOTO logError
END
@variable1 = @varaible2 / @variable3
IF @@ERROR <> 0
BEGIN
GOTO logError
END
COMMIT TRANSACTION
...
END
...
logError:
...
Increible ¿cierto?
Foy: Ahora, y el mensaje del error ¿como lo capturamos para guardarlo?
SQLServer 2000: ¿Mensaje de error? ¿Que es eso?
Así es, no hay manera de capturar el mensaje de error o como decía un articulo al respecto: "There is no supported way to retrieve the full text of an error message in SQL 2000". Bueno en realidad se supone que si hay una manera, en este articulo se explica que haciendo uso de un store procedure de sistema (xp_readerrorlog) se puede, sin embargo se requiere tener acceso al mismo siendo owner de la base de datos, a mi particularmente no me sirve esta solución (ademas no tuve oportunidad de probar esta solución por eso señalo "se supone que funciona").
En vista de esto no quedo más remedio que usar algo como esto:
Donde @Error es el numero de error que capturamos y @Mensaje es donde dejaremos la descripcion del error. El problema es que en @Mensaje se guardan mensajes como
SELECT @Mensaje= MSG.description from master.dbo.sysmessages MSG
INNER JOIN sys.syslanguages LANG ON MSG.msglangID=LANG.msglangid
WHERE MSG.error=@Error
Por lo que se puede apreciar no aparecen reemplazados los tags por lo que la informacion podría y de hecho es escasa.
Cannot insert the value NULL into column '%.*ls', table '%.*ls'; column does not allow nulls. %ls fails.
La otra opción es escribir mensajes de error personalizados dependiendo del numero de error pero llegado ha este punto ya estaba cansado de las peripecias que habia tenido que hacer. por lo que me quede con el mensaje sin reemplazar tags. Si alguien sabe alguna forma de hacerlo muy bienvenida será, siempre que la recomiendacion no se sea ¿Por que no migras a 2005?...
5 ene 2010
Feliz 2010
Ya pasaron las fiestas, las celebraciones y ya estamos de vuelta en las faenas diarias de todos los días comunes y corrientes. Espero que este 2010 sea mejor que el 2009 pero no tan bueno como el 2011.
Que soplen vientos favorables para todos mis amigos y conocidos. Y que, aunque es mucho pedir, el mundo mejore aunque sea un poquito para bienestar de todos.
Próspero 2010!
Que soplen vientos favorables para todos mis amigos y conocidos. Y que, aunque es mucho pedir, el mundo mejore aunque sea un poquito para bienestar de todos.
Próspero 2010!
22 dic 2009
Modo Dios en Windows 7
Que tiempos aquellos del DOOM donde si nos frustrábamos mucho tratando de pasar un nivel o un boss podíamos activar el modo dios y nos volvíamos invulnerables, invencibles y entonces nos desquitábamos de todo lo sufrido.
Pues resulta y acontece que el recientemente lanzado Windows 7 tiene su modo dios. Consiste básicamente en un truquillo para activar un super panel de control donde existen muchas más opciones de configuración que en el panel normal.
¿Cúal es es el truco? Creamos una carpeta y la nombramos asi: "GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}" sin las comillas. La carperta cambia de icono y queda nombrada como GodMode y como ya dijimos al explorarla lo que nos aparece es una gran gama de opciones. Yo la probé en un Windows 7 Profesional de 32 bits y la lista llega a alrededor de 275 opciones (La mayoría de accesibilidad).
La verdad no es la gran cosa, no nos volvemos ni invulnerables ni invencibles, pero es un truquillo interesante para apantallar a los amigos y ademas quién sabe sin en el futuro alguna de esas opciones extra nos saque de algún apuro.
Pues resulta y acontece que el recientemente lanzado Windows 7 tiene su modo dios. Consiste básicamente en un truquillo para activar un super panel de control donde existen muchas más opciones de configuración que en el panel normal.
¿Cúal es es el truco? Creamos una carpeta y la nombramos asi: "GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}" sin las comillas. La carperta cambia de icono y queda nombrada como GodMode y como ya dijimos al explorarla lo que nos aparece es una gran gama de opciones. Yo la probé en un Windows 7 Profesional de 32 bits y la lista llega a alrededor de 275 opciones (La mayoría de accesibilidad).
La verdad no es la gran cosa, no nos volvemos ni invulnerables ni invencibles, pero es un truquillo interesante para apantallar a los amigos y ademas quién sabe sin en el futuro alguna de esas opciones extra nos saque de algún apuro.
8 dic 2009
Datos válidos se cargan nulos desde archivos Excel
En el post OLEDB Para cagar Archivos de Excel habíamos indicado una manera de cargar datos desde un archivo Excel utilizando OleDB explicando algunas de las propiedades del string de conexión según lo entendí en ese momento.
Ahora se nos presentó un problema menor con esta aproximación: Resulta que tenemos una columna cuyas celdas traen valores que normalmente son alfanuméricos, por lo que las celdas se formatean como texto; sin embargo en un punto del proceso se modificó manualmente un par de celdas de dicha columna con valores numéricos.
A la hora de realizar la consulta las dos celdas modificadas con valores numéricos son retornadas como nulas, específicamente con el valor DBNull de .Net. Estuvimos investigando y acontece que ése es el comportamiento normal, osea así es como funciona.
Cuando utilizamos este modo de cargar datos el tipo de la columna que prevalece es el de la mayoría de las celdas. Para clarificar, supongamos que tenemos una columna con 8 celdas:
Ahora bien, hay una forma de tratar con este problema: utilizando el valor IMEX de las Extented Properties del string de conexión. IMEX se utiliza precisamente para indicar que se importaran valores de tipos mixtos, pero lo hace convirtiendo todo a texto. Como lo mencionamos en el artículo mencionado anteriormente, utilizar el IMEX=1 "significa que se tomaran los valor tal y como se FORMATEAN en las celdas" por lo que hay que valorar y sopesar el uso de esta propiedad.
En nuestra situación particular optamos por instruir al usuario del aplicativo que en caso de requerir modificar valores de la columna en cuestión se debe asegurar que las celdas se formatearan como texto, lo cual puede hacerse de manera simple: antes incluir cualquier dato utilizar una comilla simple. Ademas añadimos alertas durante la carga de que los valores nulos no se cargaran.
Algunos links que tratan sobre este asunto:
http://support.microsoft.com/kb/257819/
http://support.microsoft.com/kb/194124/EN-US/
Ahora se nos presentó un problema menor con esta aproximación: Resulta que tenemos una columna cuyas celdas traen valores que normalmente son alfanuméricos, por lo que las celdas se formatean como texto; sin embargo en un punto del proceso se modificó manualmente un par de celdas de dicha columna con valores numéricos.
A la hora de realizar la consulta las dos celdas modificadas con valores numéricos son retornadas como nulas, específicamente con el valor DBNull de .Net. Estuvimos investigando y acontece que ése es el comportamiento normal, osea así es como funciona.
Cuando utilizamos este modo de cargar datos el tipo de la columna que prevalece es el de la mayoría de las celdas. Para clarificar, supongamos que tenemos una columna con 8 celdas:
- Si 5 celdas son texto y 3 son numéricas. la consulta devolverá 5 valores (los texto) y 3 nulos.
- Si 5 celdas son numericas y 3 son texto la consulta devolverá 5 valores (los numéricos) y 3 nulos.
- Si 4 son numéricas y 4 son texto la consulta devolverá 4 valores (los numéricos) y 4 nulos.
Ahora bien, hay una forma de tratar con este problema: utilizando el valor IMEX de las Extented Properties del string de conexión. IMEX se utiliza precisamente para indicar que se importaran valores de tipos mixtos, pero lo hace convirtiendo todo a texto. Como lo mencionamos en el artículo mencionado anteriormente, utilizar el IMEX=1 "significa que se tomaran los valor tal y como se FORMATEAN en las celdas" por lo que hay que valorar y sopesar el uso de esta propiedad.
OleDbConnection cnnOle = new OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;
Data Source=C:Pruebas\test.xls;
Extended Properties=\"EXCEL 8.0;HDR=NO;IMEX=1\";");
cnnOle.Open();
En nuestra situación particular optamos por instruir al usuario del aplicativo que en caso de requerir modificar valores de la columna en cuestión se debe asegurar que las celdas se formatearan como texto, lo cual puede hacerse de manera simple: antes incluir cualquier dato utilizar una comilla simple. Ademas añadimos alertas durante la carga de que los valores nulos no se cargaran.
Algunos links que tratan sobre este asunto:
http://support.microsoft.com/kb/257819/
http://support.microsoft.com/kb/194124/EN-US/
Suscribirse a:
Entradas (Atom)