Validar cuenta de correo electrónico

Función enviada al Grupo de Noticias por Anders Altberg que valida una cuenta de e-mail.

FUNCTION ValidarCuentaEmail
  LPARAMETERS email && la cuenta
  loRegExp = CreateObject("VBScript.RegExp")
  loRegExp.IgnoreCase = .T.
  loRegExp.Pattern =  '^[A-Za-z0-9](([_\.\-]?[a-zA-Z0-9]+)*)@([A-Za-z0-9]+)(([\.\-]?[a-zA-Z0-9]+)­*)\.([A-Za-z]{2,})$'
  m.valid = loRegExp.Test(m.email)
  RELEASE loRegExp
  RETURN M.valid
ENDFUNC

Cliente-Servidor: Manejo de Fechas

Los servidores de bases de datos tienen, al igual que Visual FoxPro, la capacidad de manejar fechas. VFP tiene la capacidad de conectarse a cualquier DBMS (DataBase Management System), ya sea por medio de ODBC o de ADO, el manejo de fechas no es nada complicado como veremos a continuación.

Primero que nada, debemos tener en cuenta dos puntos importantísimos al respecto.

No existe el tipo de datos Date (Fecha)

En efecto, los DBMS no tienen un tipo de datos Date, en su lugar, se tiene un tipo de datos DateTime (Fecha-Hora), el cuál, al igual que el tipo de dato de DateTime de VFP tiene una precisión de segundos, es decir, un format Dia, Mes, Año, Hora, y Segundos. En VFP las variables DateTime se pueden definir con la función DateTime() o mapearse directamente sobre la asignación de un campo tipo DateTime:

ltFechaInicio = DateTime(lnAnnio, lnMes, lnDia, lnHora, lnSegundos)
  ltFechaFin = Cursor.tFechaFin

Los tipos de datos DateTime, a diferencia de los Date, se basan en segundos, y no en días, por lo que su aritmética varía en consecuencia, nuestro compañero Luis María Guayán ya he escrito un extenso documento sobre esto aquí:

--- Trabajar con fechas y horas en Visual FoxPro ---
http://comunidadvfp.blogspot.com/2014/09/trabajar-con-fechas-y-horas-en-visual.html

Por lo tanto, debemos tener en cuenta este detalle y acostumbrarse a tal hecho, claro está, dependiendo de tu DBMS podrías retornar otro tipo de datos, o en su defecto, sobre el cursor resultante, aplicar la conversión de datos si así fuere necesario.

No existen las fechas vacias

Los DBMS no entienden el concepto de las fechas vacias que maneja VFP, de hecho, dependiendo del manejador de base de datos, obtendrás resultados inesperados, o un error.

Entonces, ¿ Cómo debemos manejar las fechas vacias (ldFecha = {}) ?, las fechas vacias, deberían convertirse todas a valores nulos (ldFecha = .null.), y en las consultas SQL, manejar las funciones pertinentes.

--- ¿Qué es un valor null entre amigos? ---
http://comunidadvfp.blogspot.com/2014/09/que-es-un-valor-null-entre-amigos.html

--- NULL (SQL) ---
http://en.wikipedia.org/wiki/Null_(SQL)

--- Working With Columns That Contain Null Values ---
http://www.databasejournal.com/features/mssql/article.php/3399931

De este modo, si estás contemplando hacer un upsizing desde tablas DBF a un servidor de base datos, entonces, antes deberás cambiarlas a nulos todos aquellos valores que fueran vacios.

UPDATE MiTabla SET dFecha = null WHERE EMPTY(dFecha)

Trabajando con Fechas en los Servidores de Base de Datos

Una vez contemplado la anterior, podemos introducirnos al tema, y como comentaba líneas arriba, no es nada difícil, sólo debemos usar la Parametrización.

En el caso de que manejemos SQL Pass Trough (SPT), sabemos que deberíamos envíar una cadena de texto, es decir, sólo la consulta SQL, y claro, podremos olvidarnos de formatearlo para que concuerde con la manera en que tu servidor maneje los datos.

Durante mucho tiempo se ha debatido en los foros de discusión, que las fechas deberían ser mandadas con formato estándar ANSI: AAAAMMDD.HHSS (20070506.1320), la verdad que eso no es tan cierto, por lo menos en VFP, lo que debemos hacer es hacer uso de la parametrización.

Como muestra, un pequeño código que podríamos utilizar para mandar una consulta a un servidor de Base de Datos SQL Server (cualquier versión):

WITH Thisform
   ltFechaInicio = .txtFechaInicio.Value
   ltFechaFin = .txtFechaFin.Value
ENDWITH

TEXT TO lcConsulta NOSHOW
  SELECT iID, cIDFactura, tFecha, yImporte, nCantidad
     FROM DetalleFactura 
     WHERE Fecha BETWEEN ?ltFechaInicio AND ?ltFechaFin
ENDTEXT

IF SQLExec(lnHandle, lcConsulta, lcCursor) > 0
   *** Hacer algo
ELSE
   IF AERROR(laError) > 0
      Messagebox("Error en la consulta:"+laError[2])
   ENDIF
ENDIF

Sencillo? Si, la magia se realiza justo en el driver ODBC, VFP se encarga de comunicarle que es un tipo de datos DateTime y hará la conversión pertinente. Tan fácil como eso.

Retomando el caso de los valores nulos

Como mencionabamos anteriormente, los servidores de Bases de Datos no manejan el concepto de fechas vacias, por lo que a la hora de mandar ese dato, debemos "convertir" las variables a null, y así mandarlas al servidor.

WITH Thisform
   iProductoID = .txtProductoID.Value
   nCantidad = .txtCantidad.Value
   yPrecioVenta = .txtPrecio.Value   
   IF EMPTY(.txtFecha.value)
      tFechaVenta = .null.
   ENDIF
ENDWITH
TEXT TO lcSQL NOSHOW
   INSERT INTO DetalledeVenta (iProductoID,nCantidad, yPreciodeVenta, tFechaVenta)
     VALUES (?iProductoID, ?nCantidad, ?yPrecioVenta, ?tFechaVenta)
ENDTEXT

Notas adicionales

Como nota al margen, debemos también tomar en cuenta que al basarse en tipo de datos DateTime, se debe hacer especial énfasis en que los inicios y fines del día.

Como un ejemplo, supongamos que quisieramos obtener los movimientos realizados únicamente en la fecha 11 de Junio de 2007, entonces, al mandar la consulta:

lcTabla = "DetalledeVenta"
ldFechaInicial = DATE(2007,06,11)
ldFechaFinal  = ldFechaInicial+1
TEXT TO lcSQL NOSHOW TEXTMERGE
   SELECT idMovimiento, iProductoID, nCantidad, yPrecioVenta 
      FROM <<lcTabla>>
      WHERE tFechaVenta BETWEEN ?ldFechaInicial AND ?ldFechaFinal
ENDTEXT

IF SQLExec(lnHandle,lcSQL,lcCursor) > 0
  ** Hacer el trabajo con el cursor resultante
   SELECT (lcCursor)
   ***SCAN
   ***ENDSCAN
ELSE
   IF AERROR(laError) > 0
      Messagebox("Error en la consulta:"+laError[2])
   ELSE
      Messagebox("Error inesperado en la aplicacion")
  ENDIF
ENDIF

Cuando usamos la parametrización debemos revisar que los tipos de datos de las variables de VFP correspondan a los tipos de datos de la base de datos SQL, es decir, si tu tipo de datos en tu formulario es numérico y en la base de datos es caracter, entonces antes deberías cambiar la variable a enviar a tipo caracter (¿STR(lnNum, 5)?), como caso especial los tipos de datos Date en VFP son compatibles con los tipos DateTime del controlador ODBC, con la única salvedad de que estas fechas serán contemplados con la hora inicial del día.

Espero que les sea de utilidad.

Espartaco Palma Martínez

Registrar OCX / DLL en Windows Vista

Antes de Windows Vista cada vez que necesitabamos registrar una libreria ActiveX (OCX, DLL) o un EXE lo podiamos hacer de diversas maneras, una de las comunes era simplemente utilizando el comando REGSVR32 de la suiguiente manera...

regsvr32 [/u] [/s] [/n] [/i[:líneaDeComandos]] nombrelibreria.DLL o OCX

Parámetros:

• /u: Elimina el registro del servidor.
• /s: Especifica que regsvr32 se ejecute sin interfaz y que no presente ningún cuadro de mensaje.
• /n: Especifica que no se invoca DllRegisterServer. Esta opción se tiene que utilizar con /i.
• /i: líneaComandos Invoca DllInstall y le pasa una [líneaComandos] opcional. Cuando se utiliza con /u, activa la desinstalación de .dll.
• nombrelibreria.DLL o OCX: Especifica el nombre del archivo .dll que se va a registrar.
• /?: Muestra Ayuda en el símbolo del sistema.

Al tratar de instalar librerias OCX y/o DLL's en Windows Vista (Asi tambien como arhivos .EXE que necesitan ser registrados) nos damos con la desagradable sorpresa que no se puede, el SO reporta un mensaje de error que dice mas o menos :

Se cargo el modulo Libreria.ocx pero se produjo un error en la llamada a dllRegisterserver (codigo de error: 0x80004005)

Otro error encontrado es:

"Unexpected error; quitting"

Al empezar a indagar con ese problema me di con que los usuarios de VB6 y anteriores tienen el mismo problema asi que e aqui la solucion:

El problema radica fundamentalmente en que Windows Vista hace mucho mas incapie en la seguridad del sistema y ya que cualquiera de estos tipos de archivos son potencialmente peligrosos, a menos que el ususario actual sea el Admnistrador no permitira la registración de estos archivos.

Por lo tanto una solucion es loguearse en el sistema como administrador (Primero debemos activar este usuario ya que por defecto viene deshabilitado y al mismo tiempo desactivar el UAC (User Account Control), todo esto se hace dentro del Panel de control/Control de Usuarios (Debemos aclarar que no alcanza que el usuario actual tenga perfil de administrador debemos logueaes especificamente con la cuenta Administrador o Administrator en su version inglesa)

Una vez hecho esto ya podremos instalar las librerias tal como lo haciamos antes.

Una solucion alternativa y mas rapida es:

1. Clicear en Inicio
2. En "Iniciar busqueda" o "Start Search" tipear cmd
3. Una vez encontrado el icono de cmd en el menu
4. click derecho en el icono del cmd (command)
5. elegir la opcion "Run as Administrator" ("Ejecutar como Administrador")
6. Ir a la carpeta en donde se encuentran las librerias
7. Tipear nomlibreria.ext /regserver o REGSVR32 nomlibreria.ext (En donde .ext seria OCX/DLL o EXE según el caso)

Esto solucionara el problema y nos permitira probar nuestros sistemas/librerias en el nuevo SO de M$
Para mas información sobre seguridad en windows Vista:

http://technet2.microsoft.com/WindowsVista/en/library/0d75f774-8514-4c9e-ac08-4c21f5c6c2d91033.mspx?mfr=true

Daniel Salazar
www.ZondaSoftware.com.ar
Salta - Argentina

FontFace de Reportes

Me paso que todos mi reports estaban armados con la fuente 'Tahoma' y queria pasarlos a 'Arial'. Cuando termine el primero me di cuenta que necesitaba casi todo un día para terminar todos los .FRX, asi que, a facilitar la cosa.

En 7 lineas en la ventana de comando pude cambiar todas la fuentes de todos los títulos y textboxes de los informes de mi proyecto. Pueden ver en el codigo que pueden hacer varias otras cosas (ej. Cambiar el tamaño de las letras que reunan alguna(s) condicion(es), etc etc).

EL CODIGO:

SELECT NAME FROM project.pjx WHERE TYPE='R' INTO CURSOR tmp
SCAN ALL
 SELECT 0
 USE (tmp.name)
 REPLACE fontface WITH 'Arial' FOR !EMPTY(FONTFACE)
 USE IN (tmp.name)
ENDSCAN

Guillermo Gastón Giménez

Cliente-Servidor: Parametrización de Variables

Cuando manejamos la conexión a un DBMS (DataBase Management System) podemos mandar cualquier tipo de datos, no solo caracteres de texto. Aplicable a cualquier servidor de Base de Datos (Microsoft SQL Server, MySQL, PostgreSQL, Firebird, etc).

Es muy común que cuando empezamos a manejar datos de una fuente externa a VFP, es decir, a servidores de base de datos, nos encontremos con la limitación de que únicamente podemos mandar cadenas de texto en las consultas SQL.

Para apoyarnos un poco, tomaremos una típica consulta SQL...

  SELECT iID, cClave, cCliente, cRegistro
     WHERE (iID > <NumeroInferior > ) 
        AND (iID < < NumeroSuperior > )
     FROM Cliente

Donde, obviamente, el "Numero Inferior" y "Numero Superior" serían datos variables a consultar, tomados de algún formulario de VFP.

Nuestro primer intento puede ser intentar formatear la cadena, de manera a que lo que se envía sea igual que la consulta deseada:

   lcConsulta = "  SELECT iID, cClave, cCliente, cRegistro "+
                      "      WHERE (iID > " + STR(thisform.txtNumerInferior.Value) + ")"+
                      "           AND (iID < " + STR(Thisform.txtNumeroSuperior.Value) + ")"+
                      "    FROM Cliente "

Lo anterior funcionará, ya que igual, tenemos una cadena de texto y los valores, que ya han sido convertidos a cadena serán enviados tal cual a nuestro servidor.

Pero eso, al parecer, no es eficiente... Quizás lo podríamos hacer mejor, no? Pues si, como vimos en un artículo pasado, podríamos usar bloques TEXT ... ENDTEXT, para mejorar nuestra presentación:

WITH ThisForm
   lnNumeroInferior = .txtNumeroSuperior.Value
   lnNumeroSuperior = .txtNumerSuperior.Value
ENDWITH

TEXT TO lcConsulta NOSHOW TEXTMERGE
  SELECT iID, cClave, cCliente, cRegistro
     WHERE (iID > <<NumeroInferior>> ) 
        AND (iID < <<NumeroSuperior >> )
     FROM Cliente
ENDTEXT

Funciona, si, también hace lo que deseamos, enviará los datos con los valores que queremos sin ningún problema. Pero, hagamos esto un poco más complicado: ¿Qué pasará cuando querramos hacer una búsqueda en base a un dato de tipo caracter? Cambiando un poco el ejemplo, buscaremos el conjunto de datos que cumpla con la condición de encontrar los datos de un cliente con base a la clave (string) del mismo:

   SELECT iID, cCliente, cDireccion, dFechaAlta, yAdeudo
        FROM Cliente
        WHERE cClave = 'ALFKI'

Como vemos en la consulta, y en el caso específico de SQL Server, cuando se hace una query en base a datos de caracteres debemos encerrar dicho valor entre comillas sencillas, ¿sencillo? , ¿o no?

   lcCliente = Thisform.txtCliente.Value
   TEXT TO lcConsulta NOSHOW TEXTMERGE
      SELECT iID, cClave, cCliente, cDireccion
           FROM Cliente
           WHERE cClave = '<<lcCliente>>'      
   ENDTEXT

Una vez más, vemos que el ejemplo, también funciona, pero tiene un detalle: debemos formatear cada consulta de acuerdo a los requerimentos de nuestro servidor, y según sea el caso, podría que fuera diferente de un servidor a otro, además de que por lo que a mí respecta, pienso que es bastante engorroso y podría evitarse.

La Parametrización al rescate

La forma sencilla de no tener complicaciones con los distintos tipos de datos de los servidores, y los distintos tipos de datos de VFP, resulta en usar la Parametrización, ¿y que es esto?, consiste en anteponer un símbolo de interrogación justo antes de una variable:

   lcCliente = Thisform.txtCliente.Value
   TEXT TO lcConsulta NOSHOW 
      SELECT iID, cClave, cCliente, cDireccion
           FROM Cliente
           WHERE cClave = ?lcCliente
   ENDTEXT
   IF SQLExec(lnHandle, lcConsulta, lcCursor) > 0
     ***  ¿Manipular, mostrar los datos?
     *** SELECT (lcCursor)
   ELSE
      IF AERROR(laError) > 0
         Messagebox("Error en la consulta: "+laError[2])
      ELSE
         Messagebox("Error inesperado en la aplicación")
      ENDIF
   ENDIF   

Como podrás notar, en el bloque TEXT...ENDTEXT hemos prescindido de la función de TEXTMERGE, además de las comillas sencillas, y en su lugar, sólo hemos puesto un símbolo de cierre de interrogación.

¿Qué estamos haciendo?, cuando usamos la Parametrización, delegamos la función de formateo de variables al driver ODBC, VFP se encargará de comunicarle qué tipo de datos es, y casi por arte de magia, hará la conversión pertinente. ¿Sencillo?, asi es, y funcionará con todos los tipo de datos de VFP (no será el caso de objetos, no confundir). Haz el intento ;-).

Nota al margen

En los ejemplos arriba escritos hemos hecho solo consultas de datos, pero aplicará a cualquiera de los comandos de tipo DML (Data Manipulation Language) de SQL, tales como INSERT, UPDATE, DELETE, etc.:

  ** Insertar datos 
  TEXT TO lcInsert NOSHOW
    INSERT INTO Detalles (cClave, iProductoID, nCantidad, yPrecioVenta, dFechaVenta)
       VALUES (?lcClave, ?lnProductoID, ?lnCantidad, ?lyPreciodeVenta, ?ldFechaVenta)
   ENDTEXT
   IF SQLExec(lnHandle,lcInsert) > 0
      *** Datos insertados con éxito
      *** Messagebox("Datos insertados con éxito")
   ELSE
       IF AERROR(laError) > 0
          Messagebox("Error al insertar datos:"+laError[2])
       ELSE
          Messagebox("Error inesperado!!")
       ENDIF
   ENDIF

   ** Actualizar un registro 
  TEXT TO lcUpdate NOSHOW
     UPDATE Detalles SET nCantidad = ?lnCantidad 
       WHERE ( iMovimientoID = ?lnMovimiento )
  ENDTEXT
  IF SQLExec(lnHandle, lcUpdate) > 0
     *** Actualizados con exito
     *** Messagebox("Datos actualizados con éxito")
  ELSE
     IF AERROR(laError) > 0
        Messagebox("Error al actualizar el registro:"+laError[2])
     ELSE
        Messagebox("Error inesperado!!")
     ENDIF
  ENDIF

   ** Borrar registro(s) 
   TEXT TO lcDelete NOSHOW
     DELETE FROM Detalles WHERE (iFacturaID = ?lnFactura)
   ENDTEXT
   llSucess = .F.
   IF VERSION(2) >= 9
      *** Usar las nuevas características de VFP9 para conocer los registros afectados
      llSucess = SQLExec(lnHandle,lcDelete,NULL,aRowsAffected) > 0
      IF (llSucess)
         lcMessage = "Se han borrado "+STR(aRowsAffected[1,2] ) + ;
                           " artículos de la Factura "+STR(lnFactura)
      ENDIF
   ELSE
     llSucess = SQLExec(lnHandle,lcDelete) > 0
     lcMessage = "Se han borrado todos los articulos de la Factura "+str(lnFactura)
   ENDIF
   IF llSucess
      *** Registros borrados con exito
      *** Messagebox(lcMessage)
   ELSE
      IF AERROR(laError) > 0
        Messagebox("Error al intentar borrar los datos:"+laError[2])
      ELSE
        Messagebox("Error inesperado!!")
      ENDIF
   ENDIF

Espero que este artículo les sea de utilidad.

Espartaco Palma Martínez