Ingeniero en Informática

Manejadores de Bases de Datos

Compartir 0 Me sirvió 0 No me sirvió

MANEJADORES DE BASE DE DATOS

IBM Informix® Dynamic Server (IDS) 9.30 proporciona fiabilidad superior, atendiendo las necesidades de las exigentes prácticas actuales del e-business-particularmente para aplicativos que requieran transacciones de alto desempeño.

Soporta requisitos de procesamiento de transacción online, complejos y rigurosos.

Optimiza capacidades de inteligencia del negocio competitivas

Maximiza operaciones de datos para el grupo de trabajo y para la empresa en total.

Proporciona la firmeza de una administración de base de datos comprobada, mejor de su especie.

Informix Dynamic Server con J/Foundation combina las características de IDS con un ambiente abierto, flexible, empotrado de Java! Virtual Machine. IDS con J/Foundation permite que los desarrolladores de base de datos escriban lógica de negocio del lado-servidor usando el lenguaje Java!. Java User Defined Routines (UDRs) tienen completo acceso a las características de la base de datos extensible líder mundial, de la base de datos IDS. Haciendo del IDS la plataforma ideal para el desarrollo de base de datos Java.

Además de Java UDRs, el IDS está en conformidad con el estándar SQLJ para procedimientos almacenados en Java, permitiendo el uso de los paquetes Java estándar que se encuentran incluidos en el Java Development Kit (JDK). Escribir UDRs en Java proporciona aplicativos mucho más flexibles que se pueden desarrollar más rápidamente que C, y más potentes y administrables que los lenguajes de procedimientos almacenados.

Una extensión adicional de escribir UDRs en Java es escribir módulos DataBlade® en Java. Los módulos DataBlade son colecciones de nuevas funciones del lado-servidor y tipos de datos puestos en conjunto para extender el IBM Informix® Dynamic Server con el servidor de datos J/Foundation. El DataBlade Developer's Kit (DBDK) ahora soporta Java y permite el desarrollo, diseminación y depuración de UDRs en Java. La tecnología IBM Informix DataBlade es líder en la industria en extender el servidor para permitir tanto la administración de contenido rich, cuanto la lógica de negocio.

J/Foundation está provisto con IDS en muchas de las plataformas IDS 9.30 soportadas. Las plataformas soportadas incluyen Sun Solaris 32 bit, Microsoft Windows NT/2000, Linux, IBM AIX, SGI Irix, y Compaq Tru 64

Nombre del Formato:	Informix
Tipo de Formato:	Base de Datos
Descripción del Formato:	Base de datos comercial
Formato disponible en Data Junction Enterprise:	Sí
Formato disponible en Data Junction Profesional:	No (la versión Enterprise es necesaria si se desea leer o escribir datos en este formato)
Nombre del Editor:	IBM Software
Más información en:	Informix
Comentarios adicionales:	Sin comentarios

Funciones Oracle

Requisitos previos: Usted necesita saber los valores de las variables de entorno siguientes:

ORACLE_HOME

Ésta es la trayectoria a su directorio de la instalación del oráculo. Se define generalmente en la escritura de la conexión de UNIX de su usuario del oráculo y de todos los usuarios del cliente del oráculo.

ORACLE_SID

Éste es el nombre del caso de la base de datos que usted desea conectar con. También se define en el ambiente de UNIX de su usuario del oráculo y de todos los usuarios del cliente del oráculo. Descubra los valores de estas variables por el loggin adentro como usuario que pueda conectar con la base de datos en la pregunta con sqlplus. Entonces mecanografíe en su aviso de la cáscara de Unix:

prompt> echo $ORACLE_HOME
/opt/oracle/oracle/8.0.3
prompt> echo $ORACLE_SID
ORACLE

A simple PHP script using ora_* functions

<?php
putenv("ORACLE_SID=ORACLE");
putenv("ORACLE_HOME=/opt/oracle/oracle/8.0.3");

$conn = ora_login("scott", "tiger");
$curs = ora_open($conn);

ora_commitoff($conn);

$query = sprintf(&quotselect * from cat");

/* Long version */
/*
ora_parse($curs, $query);
ora_exec($curs);
ora_fetch($curs);
*/
/* Short Version */
ora_do($conn, $query);

$ncols = ora_numcols($curs);
$nrows = ora_numrows($curs);
printf("Result size is $ncols cols by $nrows rows.
");

for ($i=0; $i<$ncols; $i++) {
printf("col[%s] = %s type[%d] = %s
",
$i, ora_columnname($curs, $i),
$i, ora_columntype($curs, $i));
}

for ($j=0; $j<$nrows; $j++) {
for ($i=0; $i<$ncols; $i++) {
$col = ora_getcolumn($curs, $i);
printf(&quotval[%d, %d] = %s * ", $j, $i, ora_getcolumn($curs, $i);
}
printf("
");
}
?>

Stevel at nettek-llc dot com

<?php

putenv(
"ORACLE_SID=sid1");

putenv(
"ORACLE_HOME=/u01/app/oracle/product/8.0.5");

$handle = ora_plogon(
"SCOTT@sid1", "TIGER")or die;

$cursor = ora_open($handle);

ora_commitoff($handle);

$query = "SELECT * FROM EMP";

ora_parse($cursor, $query) or die;

ora_exec($cursor);

echo "<HTML><PRE>\n";

echo "$query\n\n";

$numcols = 0;

while(ora_fetch($cursor)){

$numcols = ora_numcols($cursor);

for($column=0; $column < $numcols; $column++){

$data = trim(ora_getcolumn($cursor, $column));

if($data =="") $data = "NULL";

echo"$data\t";

}

echo "\n";

}

$numrows = ora_numrows($cursor);

echo "\nROWS RETURNED: $numrows\n";

echo "</PRE></HTML>\n";

ora_close($cursor);

?>

Vistas y envolturas

La implementación de VFP de las vistas le permite trabajar con ellas de modo similar a como trabaja con tablas nativas. Como las trataré en detalle en este artículo, usarlas es clave para lograr ser independiente del software de soporte (back-end).

El otro concepto importante es el uso de envolturas. Por envoltura me refiero a la técnica por la cual una función o comando, como SKIP, es "envuelta" en algún código que la protege y almacenada en una función definida por el usuario, de forma tal que cada vez que se utilice, no tenga que codificar de nuevo la intercepción de errores necesaria. Por ejemplo, la función SafeSkip puede verse como:

Function SafeSkip

LParameters cAlias

llMoved = .F.

* Avoid that "EOF encountered" error

If !EOF(cAlias)

Skip In (cAlias)

If EOF(cAlias)

* Moved to EOF, retreat

Skip -1 In (cAlias)

Else

llMoved = .T.

Endif

Return llMoved

Mientras más fuentes de datos intente accesar, más código condicional necesitará escribir. Escribir código de esta forma le proporcionará los siguientes beneficios:

Crea un solo punto de mantenimiento si se necesita realizar algún cambio.
El mismo código puede accesar múltiples fuentes de datos.
Puede comenzar a codificar aplicaciones cliente/servidor utilizando software de soporte en VFP hasta que se tome una decisión acerca de utilizar MS SQL Server, Oracle, Informix, Sybase o DB/2.

Formularios de entrada de datos basadas en vistas.

Cuando se trata de formularios de entrada de datos para una aplicación cliente/servidor, puede utilizar ya sea SQL Pass-through (SPT), el cual es sencillamente pasar una cadena de SQL a través de un ODBC a la fuente de datos, o vistas remotas, que significa enunciados SQL almacenados en DBC cuyas tablas temporales resultantes se comportan muy similar a las tablas nativas de VFP. El SPT almacenará su conjunto de resultados en un cursor local, así que Usted tendrá que hacer un ciclo sobre los controles dentro de un formulario y añadir cada uno de ellos individualmente (por ejemplo, thisform.txtCustomer.Value = SQLResult.customer). Claro, actualizar el servidor requeriría que Usted creara los enunciados SQL Update, Insert, y Delete apropiados, sin mencionar la verificación de contención multiusuario que debe ser codificada también, una tarea algo tediosa y plagada de oportunidades de error. Esta es la manera en que las cosas son usualmente hechas en Visual Basic (así que Usted sabe que debe de haber una mejor manera con VFP <risa>).

Las vistas remotas, por otro lado, son increíblemente sencillas de usar. Todo lo que necesita hacer es crear una vista con la misma estructura que la tabla subyacente, abrir la vista, (realizar el SQL Select), manipular la tabla temporal local que se crea de la misma forma en que lo haría con una tabla nativa de FoxPro, luego hacer un TableUpdate. El TableUpdate automáticamente hace unos enunciados SQL Update, SQL Insert y SQL Delete por Usted y los pasa al administrador del controlador ODBC en tu estación de trabajo. El administrador del controlador ODBC utiliza el controlador ODBC que Usted ha seleccionado para traducir el SQL en la sintaxis que el software de soporte (back-end) entiende. Es así de sencillo. Yo recomiendo utilizar las vistas remotas para los ofrmularios de entrada de datos por las siguientes razones:

Un conjunto de código. El mismo conjunto de código puede funcionar con tablas VFP o con tablas remotas en un SQL Server. Usted solo tiene que utilizar vistas locales o vistas remotas de acuerdo a las tablas que se utilicen.
Desempeño. De muchas formas, las vistas pueden ser más rápidas que el SPT debido a que TableUpdate (una función de VFP de bajo nivel) crea automáticamente el código SPT por Usted. El tiempo que tomaría crear las cadenas de SQL update por Usted mismo y ejecutar el código muy probablemente sería mayor que el TableUpdate. Si Usted piensa en cuanto es lo que en realidad TableUpdate realiza (registrar la memoria intermedia [buffer] de cambios, determinar el tipo de actualización hecha, leer las propiedades de la vista, construir el lote de enunciados SQL, pasarlos al administrador de manejador ODBC, regresar una bandera de éxito/fracaso y limpiar la memoria intermedia de cambios), estoy seguro de que Usted estará de acuerdo con que puede tener mejor desempeño que el SPT.
Todo lo anterior se puede hacer sin un solo error de sintaxis.
Las propiedades de las vistas ofrecen una funcionalidad adicional sobre el SPT. Por ejemplo, para simular una cuenta de cinco BatchUpdate, se necesitaría concatenar cinco enunciados SQL con punto y comas antes de pasarlos al ODBC.

El SPT aún tiene un muy importante lugar en la aplicación cliente/servidor; Discutiré más acerca de esto en el Paso 3. Para mayor información sobre la utilización básica de las vistas locales y remotas, refierase a la VFP Developer's Guide.

Todas los comandos relacionados con datos deben de pasar a través de una función.

Casi la peor cosa que puede hacer para convertir en difícil el diseño de su aplicación, es codificar directamente (hard-code) comandos de acceso, tales como los enunciados SQL, Zap, Pack, Reindex, Seek y demás. En otras palabras, ¿luce su código como el siguiente?

Function PurgeOrders

* This function purges (deletes) orders shipped

* prior to the date passed.

LParameter dShipDate

Local lcMsg

Select Count(*) as OrderCnt from Orders ;

Where ShipDate <= dShipDate Into Cursor tcPurge

If _Tally = 0

lcMsg = "There are no orders to purge."

Else

Delete from Orders Where ShipDate <= dShipDate

lcMsg = Trim(Str(_Tally)) + ;

" orders were purged from the system."

Endif

MessageBox(lcMsg)

EndFunc

Esta clase de enunciados SQL es solo buena para accesar tablas que se pueden encontrar en su ruta de acceso. Dentro del mundo cliente/servidor puede comunicarse con las fuentes de datos por medio de un manejador de conexión (connection handle). Para las vistas, la cláusula de conexión remota <ConnectionName | DataSourceName> del comando Create SQL View habilita que una vista accese datos remotos. Y para el SQL en línea, la función de FoxPro SQLExec() es utilizada para pasar enunciados SQL al servidor por medio de ODBC. Regresa un -1 si hubo un error, 1 en caso de éxito y un 0 si una petición (query) asíncrona está pendiente de completarse aún. Como ejemplo, aquí está como obtener un cursor de órdenes de venta de un cliente dado utilizando SQL Pass-through:

llSuccess = SQLExec(goEnv.nHandle, ;

"Select * From ORDERS Where Customer = ?cCustomer",;

"tcOrders") > 0

Si Usted hubiese empleado una función de envoltura para el enunciado SQL Select dentro de PurgeOrders, entonces podría condicionalmente ejecutarlo contra datos en el SQL Server, datos en el servidor de archivos o incluso datos en la estación de trabajo local. Debe crear clases de las funciones necesarias para hacer el acceso de datos independiente del software de soporte (back-end). Aquí esta la función PurgeOrders reescrita de forma cliente/servidor:

Function PurgeOrders

* This function purges (deletes) orders shipped

* prior to the date passed.

LParameter dShipDate

Local lcSQLStr

lcSQLStr = "Select Count(*) as OrderCnt " + ;

"from Orders " + ;

"Where ShipDate <= ?dShipDate"

This.SQLExecute(lcSQLStr, "tcPurge")

If Reccount("tcPurge") = 0

lcMsg = "There are no orders to purge."

Else

lcSQLStr = "Delete from Orders ;

Where ShipDate <= ?dShipDate"

This.SQLExecute (lcSQLStr)

lcMsg = Trim(Str(Reccount("tcPurge"))) ;

+ " orders were purged from the system."

Endif

MessageBox(lcMsg)

EndFunc

Function SQLExecute

* Wrapper for VFP function SQLExec

LParameters cExecuteStr, cCursor

Local llSuccess

cCursor = Iif(PCount() = 1, "SQLResult", cCursor)

llSuccess = .T.

If goEnv.lRemote

llSuccess = (SQLExec(goEnv.nHandle, ;

cExecuteStr, cCursor) > 0)

Else && local, just macro expand cExecuteStr

* Add VFP "Into Cursor..." clause

If Upper(Left(cExecuteStr,6)) = "SELECT"

cExecuteStr = cExecuteStr + ;

" Into Cursor " + cCursor + " NoFilter"

Endif

* This should be error trapped to return llSuccess

&cExecuteStr

Endif

Return llSuccess

EndFunc

Notará el uso de Reccount() vs. _Tally. Los cursores SPT no actualizan _TALLY, así que tendrá que olvidarse de utilizar esta variable tan agradable. Sin embargo, no tendrá que preocuparse de que Reccount() contenga los registros eliminados, dado que las fuentes SQL de datos remotas no tienen una eliminación de dos etapas. Y si el software de soporte fuese una base de datos de VFP, la cláusula NoFilter prevendría que VFP creara un filtro en vez de una tabla temporal.

La segunda peor cosa que puede hacer para convertir su aplicación en un diseño cliente/servidor difícil es incluir funciones de VFP en sus SQL Selects. Sin embargo, si Usted tiene una envoltura como SQLExecute, tiene la oportunidad de leer el enunciado SQL antes de ejecutarlo y convertirlo a la sintaxis específica del software de soporte. Por ejemplo, la función de SQL Server, Convert() se utiliza para convertir tipos de datos. Así que, Usted probablemente podría imaginarse como se vería el código para encontrar "Str(" o "Val(" en una cadena y hacer una StrTran() para poner la función Convert en lugar de las anteriores. Una última opción es remover la función incluida y hacer el enunciado SQL independiente del software de soporte, luego utilizar la función VFP específica en el cursor local.

Utilice procedimientos almacenados o peticiones parametrizadas.

En términos de velocidad de ejecución, no hay nada más rápido que un procedimiento almacenado (stored procedure, SP). Dado que son precompilados y viven en el mismo edificio que las tablas, ¿qué podría ser más eficiente?. La forma en que los parámetros necesitan ser pasados al software de soporte es casi siempre diferente, así que, de nuevo, una función de envoltura se vuelve útil aquí. Por ejemplo, tome nota de la sintaxis distinta entre VFP y el SQL Server:

SQLExec("usp_GetOrders('Acme')") && VFP

SQLExec("usp_GetOrders 'Acme'") && SQL Server

Todo lo que Usted necesita para resolver esto es mejorar la función de envoltura SQLExecute para manejar procedimientos almacenados. (Le dejaré esta sencilla tarea a Usted).

Si no desea irse por la ruta de los procedimientos almacenados, siempre están las peticiones parametrizadas almacenadas en objetos de negocios. Con las peticiones parametrizadas, no tiene que preocuparse de la sintaxis de llamada de procedimientos almacenados específicos del software de soporte, ni tiene de preocuparse acerca de rescribir los procedimientos almacenados para cada fuente de datos. La disminución de desempeño que se obtiene puede bien valer el incremento en la mantenibilidad.

Usted ya ha visto como es que se ve una petición parametrizada; es solo un enunciado SPT:

llSuccess = SQLExec(goEnv.nHandle, ;

"Select * From Orders Where Customer ;

= ?cCustomer", "tcOrders") > 0

Note la sintaxis de la condición de filtrado: Customer = ?cCustomer. La sintaxis es importante debido a que: 1) la mayoría de los software de soporte la soportan; y 2) le evita tener que construir los parámetros del enunciado SQL en una cadena de caracteres específica del software de soporte:

Case lSQLServer

"...Customer = '" + cCustomer + "' And ;

shipdate <= '" + DTOS(dShipdate) + "'"

Case VFP

"...Customer = '" + cCustomer + "' And ;

shipdate <= {" + DTOS(dShipdate) + "}"

Otro beneficio es que no se topará con el "error del apóstrofe", que ocurre cuando intenta construir un enunciado SQL como el anterior, pero la variable tiene un apóstrofe en ella (por ejemplo, "Jim's"). Dado que su valor es evaluado antes de que la cadena sea enviada al servidor, terminará con comillas no apareadas correctamente y con un error de tiempo de ejecución. Como puede ver, el uso de "?" puede realmente compactar su código, así que yo recomiendo su utilización ampliamente.

Por las anteriores razones, recomiendo SPT en vez de las vistas, siempre esté creando una petición ad hoc y/o no intenta actualizar la fuente de datos. Muchas personas crean vistas para propósitos de reporteo, pero en sistemas grandes, no puedo ver la razón de incurrir en la sobrecarga de utilizar vistas cuando un procedimiento almacenado o un enunciado SPT SELECT puede ser implementado en su lugar. (A menos que deseé exponer una vista de lado del servidor a sus usuarios). El DBC de vistas del lado del cliente se puede volver demasiado sobrecargado con datos que no necesita mantener, dado que no hay propiedades de la vista que realmente necesiten ser establecidas.

Encuentre maneras creativas de limitar los conjuntos de resultados.

Dentro del paradigma cliente/servidor, los conjuntos de registros son transferidos desde el servidor hacia la estación de trabajo local, por tanto, deben ser lo más pequeños posible para reducir el tráfico en la red. Por lo tanto, de manera algo diferente a como funcionan las funciones de aplicaciones de servidor de archivos VFP, las formas se deben abrir sin datos. Esto además ayudará a mantener una carga ligera causada por las formas, aún y si la cantidad de sus datos crecen más allá de la capacidad de bases de datos de servidores de archivos, como VFP.

Y si piensa al respecto, tiene sentido dar a los usuarios solo aquello que buscan. ¿Por qué presentar al usuario una tabla que tiene 10,000 ordenes de venta abiertas cuando solo puede trabajar con un cliente a la vez? Piense que hemos programado así, durante tanto tiempo, debido a que las herramientas de búsqueda incremental nos dotaron de capacidades de navegación rápida, aún entre grandes cantidades de datos. Si bien es cierto que esto es aceptable en sistemas pequeños, la carga se volvería insoportable en una red y su aplicación no escalaría al mismo paso que los datos y los usuarios lo hicieran.

Vistas parametrizadas.

Así que si su forma se abre sin datos en el mundo cliente/servidor, ¿como le hacemos para obtener datos? Necesita proporcionarle a sus usuarios una herramienta para introducir criterios de filtrado. Estos valores servirán como parámetros de la porción Where del enunciado SQL de la vista. Usted puede proveer esta funcionalidad de muchas formas diferentes, puede elegir entre muy sencillas hasta muy complejas. Una implementación sencilla es tener una forma adherida a una vista parametrizada. Cuando un usuario entra en el modo Find, Usted puede proveer una caja de texto para introducir el valor del parámetro. Por ejemplo:

* Create this view when you create the form.

Create SQL View vOrders As Select * From Orders

Where Customer = ?cCustomer

* Open the view (with no data) in the Data Environment

* or Load when you run the form.

Use vOrders NoData

* Get the customer parameter in Find Mode

cCustomer = thisform.txtCustomer.Value

Requery() && retrieve orders for cCustomer

Una segunda técnica que proporcionaría mucha más flexibilidad es proporcionar una herramienta Query-By-Form (QBF). El QBF significa que en el modo Find, Usted puede proveer a los usuarios una manera para que introduzcan criterios de filtrado en cualquier (o solo la mayoría) de los controles de una forma. Luego construya una cadena Where SQL de acuerdo y utilícela de una de dos maneras:

1. Construya un enunciado SPT para crear un conjunto de registros de los campos importantes y el ID único. Construya una vista que esté parametrizada por el ID único. Los usuarios pueden navegar el cursor para encontrar los datos que necesitan y Usted hacer de nuevo la petición de la vista basada en la ID única.

2. Puede también utilizar la cadena SQL generada por la QBF para recrear la definición de vista remota en tiempo real. Dado que su DBC de las vistas está en la estación de trabajo, no hay problemas de contención aquí. (Más de esto en el Paso 5) .

Sugerencia:

Existen al menos dos herramientas de otras compañías de software disponibles para implementar Query-By-Form en VFP:

QBF Builder
Stonefield Query

Manejando los enlaces entre controles y a tablas de búsqueda

Este concepto de limitar el conjunto de resultados debería ser aplicado también a los controles. ¿ Qué de bueno tiene limitar las ordenes de venta a un cliente si se van a llenar varias casillas de selección (combo boxes) en la forma con datos de una tabla de búsqueda (look up)?. La lista de selección (list box) de varios miles de registros no tiene lugar en una aplicación cliente/servidor. Hay al menos dos formas de evitar este problema. Una es no utilizar esta clase de controles en tablas grandes y en su lugar utilizar una caja de texto. Luego solo lanzar una forma separada con una tabla cuando el usuario seleccione una tecla de método abreviado (hotkey) definida.

Si Usted insiste en utilizar controles con registros múltiples, puede intentar con una segunda técnica. No llene el control hasta que el evento GotFocus sea disparado. Esta técnica de enlace tardío (late binding) le evitará la sobrecarga de llenar controles no utilizados. Puede utilizar una combinación de cualquiera de estas técnicas dependiendo del tamaño anticipado de la tabla de búsqueda y solo controlarla con una propiedad y/o tabla de opciones.

La VFP Developer's Guide le ofrece una sugerencia adicional: Hacer copias de las tablas de búsqueda frecuentemente utilizadas a cada estación de trabajo. Como sea, el saber cuando mantener una versión local en sincronía con la versión del servidor me suena como una pesadilla. Por lo tanto, recomiendo una de las opciones anteriores.

Formularios Uno a Muchos

Los formularios uno a muchos deberían ser manejados como sigue. Cualquiera que sea la técnica que Usted decida utilizar para formularios de tabla única debe ser utilizada para la porción del encabezado de un formulario uno a muchos. Las vistas de las tablas hijas, deben de ser parametrizada con el ID único de la vista madre. Así que cuando Usted navegue de un encabezado a otro, a la vista hija solo necesita ser pedida de nuevo. Al utilizar este método, solo el hijo del encabezado actual necesita ser adquirido localmente.

Mantenga las vistas en su propio DBC para tratar software de soporte independientemente.

Si, en su diseño de marco de trabajo, las vistas son mantenidas en sus propios DBC, esto hará la transición a otro software de soporte más sencilla. En otras palabras, cuando Usted desea que su aplicación accese a fuentes de datos diferentes, desea mantener la mayor cantidad de piezas de su marco de trabajo intactas. Mantener las vistas en DBCs separados de las tablas (en un escenario donde VFP es el software de soporte) hará el acceso las fuentes de datos remotas una cuestión de accionar un interruptor. La implementación podría ser como sigue:

Cree un directorio llamado \VFPViews, y almacene un DBC de vistas locales en él. Nombre el DBC como AppViews.DBC (\VFPViews\AppViews.DBC).
Cree un directorio separado para cada fuente de datos que Usted desea accesar, manteniendo el mismo nombre del DBC de la vista. En otras palabras el DBC \SSViews\AppViews.DBC contendría vistas que accesan un SQL Server. Dado que frecuentemente existen varios lugares en su código donde se referirá a las vistas de la base de datos, esto evitará que tenga que escribir código condicional para cada software de soporte.
En un archivo de inicialización de su elección, almacene la información tal como el nombre DSN del ODBC, la ruta de directorios donde están almacenadas las vistas, una bandera indicando si accesa datos locales o remotos y si son locales, la ruta de directorios de donde están almacenadas las tablas de VFP.
Establezca la ruta con Set Path To... al directorio de vistas apropiado al iniciar la aplicación.
Si es un software de soporte en VFP, establezca Set Path To al directorio de red donde se almacenan las tablas de VFP.

Aunque es cierto que podría añadir el nombre de la base de datos de vistas al archivo de inicialización, frecuentemente esto ya esta codificado por toda la aplicación. El tener DBCs separados de las vistas también mantendrá el tamaño de éstas manejable. Si el software de soporte fuese una base de datos de VFP, combinarlos significaría que se necesitarían almacenar dos veces el doble del número de objetos de bases de datos. Si tal fuera el caso, Modify Database podría tomarnos un tiempo excesivamente largo en un sistema grande. También notará que el DBC de la vista (sin importar si contiene vistas remotas o locales) es mantenido localmente, no en la red para ser compartido por todos los usuarios. Utilizar esta técnica brindará mucha de la flexibilidad específica de usuario, como aprenderá luego en este artículo.

Todo este pedazo se siente como si se asumiera un almacenamiento local también, pero no está dicho explícitamente.

Utilize Locate en vez de Seek para navegar en datos locales.

Dado que todos los datos son accesados a través de enunciados SQL en una aplicación cliente/servidor, Usted pierde la habilidad de utilizar el mejor amigo de todo desarrollador de VFP, Seek. Enjuage esas lágrimas, porque hay una alternativa: Locate. Dado que los conjuntos locales de resultados serán (por definición cliente/servidor) relativamente pequeños, el comando Locate será más que suficiente para mover el puntero de registro en un cursor local o una tabla temporal.

Aquí vienen aún mejores noticias. El conjunto de resultados de una vista es de hecho una tabla temporal. Para ver a que me refiero. Abra cualquier vista y verifique el valor que regresa DBF(). Debe de ver algo como C:\WINDOWS\TEMP\76633985.TMP. Así que esta "cosa" de hecho tiene una presencia en el disco. Y en VFP, tiene una presencia en el disco que podemos indexar. Así que, siéntase libre de indexar al cursor de la vista tanto como desee si siente la necesidad de la velocidad. Pero de todas formas, yo me quedaré con Locate en vez de Seek. Dado que Locate es, además, optimizable con Rushmore, el utilizarlo con o sin índice no hará que falle, uno solo será marginalmente más rápido que el otro.

Conclusión.

Bueno, solo estamos a la mitad, pero desde ahora estoy seguro de que puede ver la luz al fondo del túnel. Las envolturas (wrappers) y las vistas son ciertamente las claves para hacer su código independiente del software de soporte. Mantener estos conceptos en mente en todo momento le ayudará a hacer aplicaciones cliente/servidor flexibles y escalables. El siguiente mes, cubriré seis pasos más y cerraré con un formulario de ejemplo que puede accesar una base de datos VFP tan bien como una base de datos SQL Server. Luego, Usted seguirá por su cuenta. Nos vemos el mes siguiente, y hasta entonces, comience a envolver.

Use claves primarias sustitutas para todos las tablas.

Incluso antes de que VFP 3.0 nos diera la capacidad de agregar claves primarias a nuestros claves, el uso de un solo campo, o grupo de campos, para identificar de manera única una fila de la tabla ha sido sugerida por muchos como una práctica sana. En aplicaciones con servidor de archivos, no obstante, en muchas situaciones en realidad no había necesidad de hacer esto; era solamente una buena idea. Sin embargo, con vistas, las reglas cambian.

Para utilizar vistas (views) actualizables, debe existir un clave primaria en la tabla en la cual se basa la vista (generalmente no actualizo los datos de una vista multitabla). La razón es que debido a que la vista crea un resultado local establecido cuando se abre (USE <NombreVista>), usted necesita algún mecanismo para poder encontrar el registro subyacente en el servidor que está tratando de actualizar. Esto no siempre era necesario en un modelo de servidor de archivos, donde un registro compartido puede ser directamente editado.

Para que las actualizaciones funcionen, las vistas requieren que usted establezca la propiedad KeyField en tiempo de diseño en el Diseñador de Vistas (View Designer) o con DBSETPROP("Viewname.KeyField1", "Field", "KeyField", .T.) o establezca la propiedad KeyFieldList en el cursor abierto en tiempo de ejecución usando CURSORSETPROP("KeyFieldList", <lista delimitada por comas de los campos de la clave primaria>).

En cualquier, la vista utilizará los campos de clave (key fields) para encontrar el registro en el servidor en el que usted ha ejecutado SQL Update o SQL Delete. Las claves también serán utilizadas para detectar los conflictos de la actualización, reportar un error si alguien ha borrado el registro que usted está intentando actualizar o ha cambiado el clave. Aparte de ser una necesidad para las vistas actualizables, agregar claves primarias a sus tablas también hace que solicitar un registro en particular sea más simple. Usted descubrirá que en el mundo cliente/servidor necesitará a menudo esa capacidad.

El argumento para los claves sustitutas.

Si usted tiene campos múltiples que conforman sus claves primarias, sugiero utilizar además una clave substituta generada por el sistema. Al tener este campo, típicamente de tipo entero, le dará el lujo de una identificación única de la fila que le dará gusto tener. Además, para las tablas hijas Usted querrá agregar una campo entero adicional como clave externa (foreign). Usted lo llenaría con la clave primaria sustituta del padre (parent) antes de grabar al hijo (child).

Las ventajas de las claves sustitutas incluyen uniones (joins) más rápidas, actualizaciones más rápidas, eliminaciones más rápidas y la recuperación simplificada de los hijos de un padre. La única desventaja está en generarlas. Yo utilizo una tabla de sistema de números consecutivos, contiene una fila por la tabla en la aplicación, pero esto puede causar problemas de conflicto multiusuario si no tiene cuidado. Debido a que estas claves realmente no tienen significado (por eso también se llaman claves abstractas), usted no debe tratar de obtener el siguiente número secuencial del servidor mientras que está a mitad de una transacción. Esto puede crear demasiado conflicto en la tabla del sistema cuando usted necesita las claves primarias para una tabla muy activa. Es mejor conseguir la clave exterior de la transacción y arriesgarse a perderla si una actualización falla.

Otra idea puede ser utilizar una de las técnicas para generar una identificación única localmente, eliminando el viaje al servidor y cualquier conflicto multiusuario posible. Igual como cuando nunca he dejado que se vaya ningún contratista de mi casa sin haberme recomendado a un buen reparador de techos, nunca dejo que una conversación con un desarrollador termine sin preguntar por su técnica para la generación de identificaciones únicas. Dos interesantes que he escuchado que usan la generación del lado del cliente son:

1. Utilice un GUID. Son de 26 caracteres de largo, (supuestamente) únicas en todo el mundo y rápidas para generarse. No son hermosas, pero valen la pena.
2. Consiga una identificación única de una tabla del sistema del lado del servidor al iniciar la aplicación y después utilice una propiedad local de la aplicación como un contador. Concatene los dos para generar una cadena alfanumérica única. Aunque estoy simplificando un poco, creo que esta técnica es utilizada en Code Book.

Agregue una columna de tiempo a cada tabla.

Las aplicaciones cliente servidor utilizan casi exclusivamente un bloqueo optimista (optimistic locking). Debido a eso, la verificación de conflictos multiusuario se convierte en más que un desafío de implementar. Debe recordarse continuamente mientras codifica: "quizás no tengo la última versión de estos registros".

Aunque la clave primaria se utiliza para detectar conflictos de actualización, su capacidad se limita a detectar si otro usuario ha suprimido el registro que usted está intentando actualizar o si ha cambiado la clave. La clave primaria no le ayudará a determinar si otro usuario a hecho los cambios a los campos que no son parte de la clave antes de hacer efectivos sus cambios.

Típicamente, las aplicaciones cliente/servidor utilizan una cierta forma de columna con una marca de tiempo (timestamp), una que se modifica como parte de cada actualización, para indicar la última versión de un registro. (Digo "una cierta forma de marca de tiempo" porque el tipo de dato puede ser casi cualquier cosa). Esta columna entonces es revisada en el servidor durante cada actualización para determinar si está en conflicto con la versión local de la estación de trabajo. Por ejemplo, una vista de VFP pudo generar el siguiente estatuto SQL después de actualizar la vista del cliente:

Replace state With 'NY' For city = 'New York' In vcustomers

TableUpdate(.T., .F., "vcustomers"):

* This is what is auto-generated by the view

* and passed to the server.

* There would be one of these per updated record.

Update customers Set state = 'NY' ;

Where cust_pkey = ?vcustomers.cust_pkey and ;

timestamp = ?vcustomers.timestamp

Si este estatuto de actualización SQL falla con un error de conflicto de actualización (Update Conflict), usted puede reportar a su usuario que alguien modificó este registro mientras lo editaba. Lo que haga después depende de que tan amable sea. En última instancia, o debe hacer una solicitud (query) de nuevo o puede intentar enviar un TableUpdate otra vez con el parámetro Force activado (que no se recomienda a menos que proporcione al usuario una comparación campo por campo de los cambios).

La propiedad de la vista, WhereType, es responsable de la verificación de conflictos multiusuarios. Usted tiene cuatro opciones para determinar qué campos son comparados cuando se genera la porción de la verificación de conflictos del estatuto SQL. Key and Modified Fields (clave y campos modificados) y Key and Updatable Fields (clave y campos actualizables) suenan como funciones poderosas, pero siento que en la mayoría de los casos estas opciones son demasiado peligrosas como para implementarse. (No me gustaría que el usuario 1 y el usuario 2 actualizaran dos columnas diferentes del mismo registro sin que cada uno conociera primero los cambios del otro).

Esto nos deja Key Fields Only (campos de clave) y Key and Timestamp (clave y marca de tiempo). Key and Timestamp solamente es soportada si su base de datos soporta una columna de tipo marca de tiempo (timestamp). Esta columna es modificada automáticamente por el servidor en cada actualización. La aplicación cliente no mantiene este campo, la vista solamente incluirá la columna en la verificación de conflictos.

El SQL Server tiene soporte para una columna de marca de tiempo. De hecho, el asistente SQL Server Upsizing Wizard tiene una opción para crear una columna de marca de tiempo para cada tabla. La columna no es realmente de tipo de dato datetime, sino más bien una cadena única generada por el sistema. La belleza de ella es que el servidor la maneja automáticamente y que es mucho más exacta que el tipo de dato datetime (nunca tendrá que preocuparse por dos usuarios actualizando a la misma hora exacta).

Algunos comportamientos de los que hay que estar enterados al usar la columna de marca de tiempo del SQL Server:

Si usted vuelve a hacer la petición (query) después grabar, la columna de marca de tiempo en el cursor de su vista local estará actualizada con el valor actual en el servidor. Así, los intentos subsecuentes de grabar el mismo registro fallarán con un error de conflicto de actualización (Update Conflict) cuando se comparen las dos marcas de tiempo.

Soluciones para las limitaciones del asistente Upsizing Wizard:

El asistente de SQL Server Upsizing Wizard tiene muchos problemas que lo hacen, en mi opinión, casi inutilizable. La mayoría de la gente que conozco ha tenido que escribir sus propias herramientas para resolver las limitaciones. Una virtud que lo salva es que el código fuente de todos los asistentes y generadores ahora viene con la versión 6.0 de VFP. No es realmente tan difícil modificar el código para superar sus limitaciones. El código fuente está situado en \<localización de VFP 6.0>\Tools\Xsource\Xsource.zip.

Así que la clave y la marca de tiempo suenan excelentes para el SQL Server, pero ¿qué hay sobre los otros sistemas de soporte (back-ends) que no soportan una columna de marca de tiempo? ¿Y cómo puede mi prototipo con vistas locales de una base de datos de VFP funcionar con el mismo conjunto del código? Mi solución es agregar mi propia columna de marca de tiempo y mantenerla del lado desde el cliente o desde un disparador de actualización del lado del servidor. Entonces convierte el campo en un KeyField (campo de clave) (véase el paso 7) y utiliza Key Fields Only WhereType. Así que su KeyFieldList podría ser cust_pkey y timestamp. (Note que los campos en la propiedad de KeyField o KeyFieldList de una vista no tienen que ser claves primarias o candidatas).

Usted puede utilizar una columna de tipo datetime para este propósito. Sin embargo, la columna datetime de VFP tiene precisión de un segundo solamente, así que es posible que dos usuarios puedan actualizar el mismo registro dentro del mismo segundo. Si usted siente que esto es un problema potencial para su aplicación, utilice otra técnica para generar un número o cadena única. Yo utilizaba esta solución hasta que empecé a usar SQL Server e incluí su columna de marca de tiempo. (Dado que usted no tiene ningún control sobre este nombre de campo, puede llamar su columna de marca de tiempo en VFP algo diferente para que no haya conflicto cuando cambie a SQL Server). Entonces puede simplemente cambiar el WhereType a Key and Timestamp (clave y marca de tiempo) y ya está listo.

Vida sin fechas.

Era un poco inquietante, bueno, quizá era más como una sacudida repentina, descubrir que el SQL Server, como la mayoría de las bases de datos del grandes, no soporta un tipo de dato para fechas (date). Debe utilizar un campo de tipo datetime. Si usted está convirtiendo una aplicación existente de VFP, que utiliza campos de fecha (date), los problemas podrían ser muy extensos. Realmente depende de cómo utiliza las fechas su aplicación y de cuánto le importa ver 12:00:00 al final de sus campos de la fecha. He resumido los problemas a los que me he enfrentado así como sus posibles soluciones.

Los controles limitan hasta los campos de la fecha.

En los casos donde es simplemente inapropiado mostrar la porción de la hora de un campo del datetime, obviamente usted tiene que realizar alguna clase de truco para perder la hora predeterminada de 12:00:00 AM. Tiene varias opciones. Usted podría utilizar DBSetProp para cambiar el datatype de la definición de la vista de datetime a date. (Como se mencionaba en la parte 1, teniendo un DBC local de vistas elimina cualquier problema de conflicto multiusuarios).

Create SQL View vOrder Remote Connection ;

Remote1 As Select * from orders

DBSetProp("vOrders.orderdate", ;

"Field", "DataType", "D(8)")

Use vOrders

Hacerlo así truncará no sólo la porción del tiempo, sino que también le proporciona un campo de tipo fecha (date) de VFP en su vista, permitiendo a su código específico de fechas funcionar sin cambiarlo. Y afortunadamente, cuando usted ejecuta una TableUpdate en una vista con un campo del tipo fecha en él, se le anexa una hora predeterminada de 12:00:00:00 AM automáticamente en el SQL Server... sin error.

Si usted tiene controles que no estén enlazados a una vista sino a un cursor de solo lectura SQL Pass-through (SPT), puede utilizar la función de conversión de tipos de datos del software de soporte (back-end) para hacer el truncamiento. Aquí está un estatuto SQL que se podría pasarse al SQL Server que haría exactamente eso:

SELECT orderid, ; customerid, ; CONVERT(char(10), orderdate, 101) as orderdate ; from orders

Observe que 101 refiere al argumento opcional de estilo de la función del CONVERT. 1 indica formato americano, mm/dd/yy. Luego le suma 100 si desea el siglo incluido.

Para hacer que la función CONVERT funcione para datos locales también, usted puede crear un procedimiento almacenado (stored procedure) llamado "Convert" en la base de datos de vistas. Haga que acepte los tres argumentos de la función de CONVERT del SQL Server y, si se le pasa un datetime, que regrese SubStr(TToC(pDateTimeField), 1, 10). Usted también necesitará escribir un procedimiento almacenado Char para manejar el tipo de dato de la función del SQL Server, char(10).

Los campos datetime no pueden estar "vacíos".

Como si perder los campos de fecha no fuera ya bastante malo, usted también debe enfrentarse con el hecho de que los campos datetime no pueden estar vacíos en la mayoría de las bases de datos. (Hay un mundo completo de funcionalidad limitada más allá de FoxPro, ¿verdad?) Las columnas datetime deben ser llenadas por una fecha y hora válidas o ser nulas (Null).

Si usted permite que sus campos datetime acepten Null, solucionará rápidamente el problema de la interfase de usuario pero probablemente generará otros. Podría experimentar resultados inesperados al introducir ciegamente Nulls. (Por ejemplo, la comparación de dos fechas donde una es nula devuelve Null, Empty (FechaNula) devuelve .F., etcétera). Pero si usted está preparado para enfrentar estos problemas, Null realmente es práctico al presentar datos a los usuarios gracias al comando de ambiente Set NullDisplay to de VFP y a la propiedad NullDisplay de los controles como la caja de texto (text box).

Si usted no desea utilizar Nulls, VFP y el SQL Server son en realidad buenos con usted. El enviar una fecha vacía al servidor del SQL no causa ningún error. Sin embargo, el SQL Server creará un datetime predeterminado de 01/01/1900 12:00:000 AM. Ahora, cuando usted solicita esos datos, usted verá 01/01/1900 en el cursor local, suponiendo que usted ha utilizado alguna de las técnicas discutidas anteriormente para truncar la hora. No creo que sea algo tan horrible como para que un usuario no deba verlo, pero si usted ha elegido establecer Set Century Off, 01/01/00 parecerá como el 1 de enero del 2000. (Como si los problemas con el año 2000 no fueran suficientes, ¡al cambiar a SQL Server se crearán problemas del año 1900!)

He creado tres posibles soluciones. La primera es agregar un valor predeterminado a todos los campos datetime, uno que ponga en claro que esta es una fecha falsa, como 01/01/9999. (Observe que el tipo de dato datetime tiene un rango de fecha del 1 de enero de 1753 al 31 de diciembre del 9999). Una vez más usted necesitaría establecer Set Century On para distinguirlo del 1999. Una opción similar es agregar un valor predeterminado de la columna a todos los campos datetime que sigan alguna regla de negocios. Por ejemplo, todas las fechas de envío (Ship Date) pueden estar predeterminadamente a ocho semanas después de la fecha de la orden (Order Date), que es un campo requerido.

La tercera opción implica más malabarismos. ¿No sería fantástico si hubiera alguna manera de borrar cada fecha igual a {01/01/1900} en el cursor de la vista abierta, no enviar ninguna actualización al servidor y no dejar ningún cambio pendiente? Bien, puede hacerse y es algo como esto:

Procedure OpenView

LParameters pcView

* Retrieve data form server

Use (pcView) in 0

* Prevent update statements from going to server

CursorSetProp('SendUpdates', .F., pcView)

* Strip 01/01/1900 out of this cursor

RemoveDefaultDates(pcView)

* Remove pending changes/clear the change buffer

TableUpdate(.T., .T., pcView)

* Restore update capability to view

CursorSetProp('SendUpdates', .T., pcView)

Por brevedad, no proporcionaré el código para la función RemoveDefaultDates. Pero todo lo que lo hace es un ciclo por todas las columnas con campos del tipo fecha (date) y los substituye por {} si son iguales a {01/01/1900}. Ahora todas las pantallas de entrada de datos se verán y funcionarán como lo hacían cuando el software de soporte (back-end) era solo VFP.

Bien, esto funciona para las vistas, pero qué hay sobre los cursores del SPT? Solo necesita ejecutar la función RemoveDefaultDates sobre cualquier cursor que será presentado eventualmente al usuario.

Diferencias entre los cursores SPT remotos y cursores SPT locales:

Los cursores del SQL Passthrough son de solo lectura cuando están creados de fuentes de datos de un servidor de archivos, pero de son de lectura/escritura cuando están creados de una fuente de datos cliente/servidor. Así pues, si usted está haciendo prototipos localmente, por supuesto necesitará cambiar el cursor a lectura/escritura antes de modificarlo.

Matemáticas de fecha.

Usted necesita estar atento de cualquier matemática de fechas que pudiera tener en su aplicación. Dado que tiene campos datetime en el servidor (y puede tenerlos en un cursor local también) donde tenía originalmente campos date, pueden ocurrir errores en los cálculos. Por ejemplo:

?Date() + 20 && 03/08/99 + 20 = 03/28/99

?Datetime() + 20 && 03/08/99 10:35:15 PM + 20 = ;

&& 03/08/99 10:35:35 PM!

* against SQL Server:

* ExpectedDate is 14 DAYS after order date

Select orderdate, ;

Orderdate + 14 as ExpectedDate ;

From Orders

* against VFP:

* ExpectedDate is 14 SECONDS after order date

Select orderdate, ;

Orderdate + 14 as ExpectedDate ;

From Orders

Puede ver que el agregar un número a un campo datetime puede tener resultados diferentes basados en el software de soporte (back-end). Es difícil decir si se agregarán segundos o días. Una solución podría ser convertir el número incremental en una función. De ese modo, Usted tiene lo necesario para determinar cual es el software de soporte y proporcionar los cálculos apropiados.

Evitar esa sensación de Empty() con los Nulls.

Si usted es como yo, quizás usted ha aprovechado la flexibilidad que proporciona la función Empty() de VFP. Empty(eExpression) funciona para cualquier tipo de datos, excepto los objetos. Puede detectar cero, una cadena vacía, una fecha vacía o falso lógico con esta una función sin ni siquiera verificar el tipo de dato. Mala movida.

Los problemas pueden ocurrir porque después de cambiar a SQL Server, puede ser que encuentre algunos valores inesperados de funciones y de solicitudes (queries). Puede ser que incluso estén en un tipo de datos diferente al que usted esperaba. Cuando estos valores se evalúan con Empty(), o cualquier función en este caso, podría causar problemas importantes. Por ejemplo:

?Empty({}) && true

?Empty({01/01/1900}) && false

?Empty(Null) && false

Usted ha visto el problema con {01/01/1900} en el paso 9, la vida sin fechas, así que sabe lo que puede ocurrir. Borrarlos localmente parecen ser la solución más fácil. ¿Pero qué hay sobre el problema de Null? La mayoría sabe que nulo no es vacío, pero ¿sabía que incluso si usted no tiene ninguna columna en su base de datos que acepte Null, puede ser obtenga valores Null del servidor? Intente esto en el SQL Server:

Function GetMaxOrderQty

lcSQL = "SELECT MAX(Quantity) AS nMaxQty" +;

" FROM [Order Details] " +;

" WHERE ProductID = 99 "

SQLExec(lcSQL, "cBigOrder")

If Reccount("cBigOrder") > 0

lnRetval = 0

Else

lnRetval = cBigOrder.nMaxQty

Endif

Return lnRetval

¿Cuál es el tipo de dato del valor de retorno? Depende. Si se encontraron registros para ProductdID = 99, la respuesta es numérica. Si no hay registros encontrados para ProductdID = 99, la respuesta es Null, a pesar de que la columna de cantidad (Quantity) no soporta valores Null.

La razón es que en solicitudes SPT para el SQL Server, usted no obtendrá un cursor resultante sin registros para solicitudes de agregación como esta. Usted obtendrá un registro sin importar si se encontraron coincidencias, a menos que usted tenga una cláusula Group By una columna que no sea de agregación. Y en las columnas de agregación tendrán un valor Null. Eso podría causarle problemas en muchos lugares si no tiene cuidado de evitarlo.

En el ejemplo precedente, lnRetval sería nulo porque no hay ningún ProductID = 99. Para evitar obtener valores nulos, usted tiene varias opciones. Por supuesto, encontrar todas las funciones de agregación en su código y hacer un IsNull() el chequeo es una manera. Podría también escribir una envoltura (wrapper) para Empty, quizás IsEmpty, que detecte Null y 01/01/1900 también. Esto se puede utilizar para verificar los valores de diversos tipos de datos sin temor de encontrar resultados inesperados.

fialmente, agregando la función Count(), como en Count(*) as Cnt, a todas las solicitudes como éstas, le da una manera común de verificar si hay un valor retorno. La columna Cnt será siempre numérica, así que ahora puede verificar si Cnt > 0 en vez de Reccount() > 0 sin temor a los Null.

El caso para los controles no enlazados.

Ya ha visto muchos problemas al trabajo con los campos que son de diferentes tipos de datos, dependiendo del software de soporte (back-end). Yo los veo también. Estos problemas hacen que sea muy difícil de escribir un conjunto del código para accesar múltiples fuentes de datos. Obviamente, no todas las aplicaciones requieren tal flexibilidad, pero para los que necesiten o quieran esta funcionalidad, los controles no enlazados (unbound) pueden ser la respuesta.

Los controles no enlazados en un formulario no tienen tipo de dato. Usted toma el resultado de una solicitud y esencialmente "pinta" los controles con los valores del contenido del campo. Eso le daría lo necesario para manipular los datos de cualquier manera que necesite antes de presentarlos al usuario.

Esto proporciona gran flexibilidad, pero también una tonelada de codificación. ¿Puede usted imaginarse cuánto código tomaría para leer los datos, pasar por todos los controles, para pintar la forma y luego pasar de nuevo por los controles para crear el código SQL que escribirá las actualizaciones al servidor? Eso sin mencionar el tener que agregar el código de validación de tipo de dato a nivel de cada campo que obtiene cuando usa controles enlazados (bound). El desarrollador promedio de FoxPro esta tan acostumbrado a usar los controles enlazados que preferiría masticar vidrio antes que escribir todo ese tedioso código. Debe haber una manera mejor.

Si tuviera que vivir mi vida otra vez, cambiaría solamente una cosa: Habría creado otra capa de abstracción de datos. (Bueno, dos cosas: también habría comprado acciones de Microsoft hace 10 años. ¿Quién sabía?) La capa adicional sería implementada en la forma de un cursor de lectura/escritura con la misma estructura y contenido del resultado de la vista.

Los controles se pueden estar todavía enlazados a una fuente de datos, mientras que al mismo tiempo usted tiene la capacidad de manipular el cursor de cualquier manera antes de presentarlo. El proceso sería algo como esto:

Procedure Load

* For this test, open the form with data.

Use vOrders In 0

* Get a copy of the result set.

Select * from vOrders Into Cursor cOrders1 NoFilter

* Make a read-write copy of cOrders1.

Use (DBF()) In 0 Again Alias cOrders

* Close the temporary read-only cursor.

Use In cOrders1

* Now the Init of the controls fire,

* which are each bound to cOrders.

* cOrders will be the form's master alias.

EndProc

Ahora solo edite el formulario como de costumbre. En Save, vacíe el cursor editado nuevamente dentro de la vista y ejecute una TableUpdate en ella. Todo el marco de trabajo basado en vistas discutido anteriormente sería aplicable, simplemente está usando una capa adicional más. Y con conjuntos de resultado pequeños, un requisito cliente/servidor, junto con el veloz motor de datos de VFP, el desempeño no debe ser un problema.

Al darse usted mismo esta oportunidad de manipular los datos antes de presentarlos, obtiene lo mejor de los controles enlazados y no enlazados. Esto hará posible la adición de nuevas funciones donde los datos subyacentes no coinciden con lo que ve el usuario, por ejemplo, de diferentes monedas, multilingüe y las representaciones carácter de datos como 4 DOZ (4 dozen, cuatro docenas).

Creando un formulario que tenga acceso a múltiples software de soporte

He proporcionado un formulario que es indicativo de cómo Usted puede diseñar un formulario que necesite tener acceso a fuentes de datos múltiples. Es tosco y sucio, con todo el código de nivel de instancia, para facilitar el aprendizaje, pero siempre podrá mejorarlo una vez que comprenda el diseño. También por simplicidad, he creado solamente un campo de filtro y no he implementado Query by Form.

Antes de que usted pueda ejecutar la forma, haga lo siguiente: extraiga los archivos y las carpetas, que están en el archivo o código, en cualquier directorio. Usted encontrará el formulario Orders, los gráficos BMP para completar el formulario y main.prg. El subdirectorio AppData contiene una copia de la base de datos Northwind Traders en formato de VFP. (Utilicé el asistente de transformación de datos del SQL Server para hacer esto). El directorio SSViews contiene una vista remota, vOrders, en un DBC llamado AppViews. De manera similar, el directorio VFPViews contiene una vista local, vOrders, en un DBC llamado AppViews. (Revise el paso 5 en la primera parte del artículo para más información sobre la estructura de archivos y directorios).

Ejecute la versión 6.0 de VFP y fije el valor por defecto al directorio donde extrajo los archivos. Tenga el SQL Server 7.0 instalado y ejecutándose. En el panel de control, cree un DSN ODBC de usuario que conecte con la base de datos Northwind Traders y llámelo NORTHWIND_SS7.

Para ejecutar el formulario contra el SQL Server, ejecute: MAIN("NORTHWIND_SS7"). Para ejecutar el formulario contra VFP como software de soporte, ejecute: MAIN("NORTHWIND_VFP"). Como usted puede ver en la figura 1, la barra del título indica la fuente de datos. Elija la Find (encontrar), introduzca un cliente como "VINET" y después elija Retrieve (extraer). Los cinco pedidos para este cliente serán extraídos del servidor.

Formulario de ejemplo.

No se emocione mucho buscando código mágino, porque realmente no hay ninguno. De hecho, no sólo es simple, sino casi idéntico al código que usted vería en un formulario enlazado a tablas intermedias.

Las únicas diferencias son la adición de la cláusula NoData del comando del USE en Load, la configuración de la variable privada cCustomer que sirve como el parámetro de la vista y la llamada subsiguiente de la función de Requery que extraerá los datos para el cliente apropiado.

Éstos son los únicos dos procedimientos que pudieran generar algún interés remoto:

PROCEDURE Load

* Important for local views

Set Exclusive Off

* Need this for table buffering

Set MultiLocks On

Set Data To AppViews

* No data on load, please

Use vOrders NoData

* Set optimistic table buffering

CursorSetProp("Buffering", 5)

ENDPROC

PROCEDURE cmdfind.Click

PRIVATE cCustomerID

cCustomerID = ""

IF Thisform.PendingChanges()

WITH Thisform

.Lockscreen = .T.

IF Not Thisform.lFindMode

thisform.lFindMode = .T.

* Change to find mode

this.Caption = "\<Retrieve"

.SetAll("Enabled", .F., "textbox")

.SetAll("Enabled", .F., "_commandbutton")

.txtCustomerID.Enabled = .T.

.txtCustomerID.Setfocus()

ELSE && In find mode, so Retrieve

.SetAll("Enabled", .T., "textbox")

.SetAll("Enabled", .T., "_commandbutton")

this.Caption = "\<Find"

.txtCustomerID.Enabled = .F.

cCustomerID = .txtCustomerID.Value

Requery()

thisform.lFindMode = .F.

ENDIF

.cmdfind.Enabled = .T.

.txtOrderID.Enabled = .F.

.Refresh()

.Lockscreen = .F.

ENDWITH

ENDIF

ENDPROC

SQL

SQL se ha establecido claramente como el lenguaje estándar de base de datos relaciónales. Hay numerosas versiones de SQL.

La versión original se desarrollo en el laboratorio de investigación de San Jose de IBM. Este lenguaje, originalmente denominado “Sequel” se implemento como parte del proyecto “ System R “ , a principios de 1970.

El lenguaje “Sequel” ha evolucionado desde entonces y su nombre ha pasado a ser SQL (Structured Query Lenguaje)” lenguaje estructurado de consultas”. Actualmente, numerosos productos son compatibles con el lenguaje SQL.

En 1986, ANSI(Instituto Nacional Americano de Normalización) e ISO(Organización Internacional de Normalización) publicaron una norma SQL, denominada SQL-86.
En 1987, IBM publico su propia norma de SQL corporativo, interfaz de base de datos para (Arquitecturas de aplicación a sistemas) SAA-SQL.
En 1989 se público una norma extendida para SQL denominada SQL-89, y actualmente los sistemas de base de datos son normalmente compatibles al menos con las características de SQL-89. La versión actual de la norma SQLANSI/ISO es la norma SQL-92

En este apartado presenta una versión general de SQL basada en las normas SQL-89 y SQL-92. se debe tener en cuenta que algunas implementaciones de SQL pueden ser compatibles solo con SQL-89, no siendo con SQL-92.

SQL incorporado permite el acceso a una base de datos desde un programa escrito en un lenguaje anfitrión, pero no proporciona ninguna asistencia en la presentación de los resultados al usuario o en la generación de informes.

La mayoría de los productos comerciales relacionados con base de datos proporcionan un lenguaje a la hora de crear la interfaz de usuario y dar formato a los datos para la generación de Informes.

Estos lenguajes especiales se denominan lenguajes de cuarta generación.

Conclusión.

Espero que usted no deje que ninguno de estos problemas lo disuada de migrar a SQL Server. Sí, es mucho trabajo. Pero es más aburrido que complicado. Espero que este artículo le ahorre mucho tiempo al informarle de muchos de los problemas antes de que usted incluso comience.

Respecto a tener un conjunto del código que tenga acceso a una base de datos de VFP así como bases de datos cliente/servidor, no la recomiendo para el largo plazo. Hay un demasiado código condicional requerido y duplicación de las herramientas que se deben escribir para asegurarlo. Al final, usted terminará probablemente con un sistema que será ineficaz con todos el software de soporte, aunque siempre podrá superar la situación agregando más hardware. Yo usaría vistas locales solamente si planeara definitivamente cambiar al servidor del SQL, Oracle, etcétera. Después de la etapa de prototipos, recomiendo que usted migre gradualmente su código para trabajar remotamente solamente.

La capacidad del SQL Server 7.0 para trabajar sobre los Windows 95/98 y NT y muchas características nuevas hacen la migración de VFP un proceso mucho más sencillo. Puede servir fácilmente como su solamente software de soporte, mientras que usa el motor de los datos de VFP para procesar los datos extraídos del servidor. Juntos, hacen a un equipo perfecto.

Tal vez te pueda interesar:

Descargar

Enviado por:	Cesarmorelia
Idioma:	castellano
País:	México

Palabras clave:

Informática Computación Estructura de información Administración Editores Oracle Formato Vistas Envolturas Comandos Entradas Almacenados Peticiones SQL (Structured Query Language)

Te va a interesar