Ver Mensaje Individual
  #2  
Antiguo 14-10-2004
axelbb axelbb is offline
Miembro
 
Registrado: oct 2004
Posts: 127
Reputación: 20
axelbb Va por buen camino
A ver....

Bueno, mientras esperás que te conteste alguien que sepa, te cuento que estoy más o menos en lo mismo. Estoy probando alguito de Oracle, un poco más de PostgreSQL y algo de FireBird (e Interbase). Son opciones, pero tienen sus diferencias.

En primer lugar, los servidores SBD traen un sistema tipo consola donde podés hacer las consultas (conseguite un manual de lenguaje SQL, que hay miles en la web). Si bien SQL pretende ser un estándar, la verdad es que hay cosas que te van a funcionar en unos y no en otros...

En el directorio bin (al menos en los servidores que te mencioné se crea) hay una serie de ejecutables que hacen diferentes cosas en modo consola (crear bases de datos, dar alta o baja a usuarios, levantar o bajar el servidor, etc.). Habrá alguno que se llame algoSQL, que te permite ejecutar esas famosas consultas SQL.

Vienen herramientas que permiten elaborar "visualmente" las tablas, indices, procedimientos y todo eso (en realidad, generan el código SQL respectivo para después ejecutarlo). No sé qué traerá SQL Server como herramientas de desarrollo. Consultá el manual o buscate algo de información.

Desde Delphi, hay muchos componentes que permiten acceder a los motores y trabajar mediante las sentencias SQL. Lo mínimo que necesitás poner en una ficha serían un TConnection y un TQuery. El primero es el que dá la conexión, mediante propiedades como Database, Hostname, Protocol y Connected. Generalmente necesitas pasarle un usuario y un password, para lo cual están las propiedades respectivas o podés pedirlos en tiempo de ejecución con la propiedad LoginPrompt. Si todas estas palabras te resultan muy raras, tendrás que comenzar por informarte sobre ésto (por ejemplo, para poder usar una PC como servidor de prueba, vas a tener que hacer que tenga IP fija, que es el hostname).

Ah, es fundamental, obvio, que el servidor esté activo (dependerá de cada uno cómo se levanta el servicio) y tenga la base de datos creada. Eso es otra cosa que empieza a importar: antes de usar el programa cliente, habrá que llamar el servicio del SBD y antes de apagar la PC servidora hay que darle de baja al SBD de manera correcta.

Bueno, es un tema larguísimo y difícil es guiarte cómo hacer las transacciones desde tu programa o generar procedimientos almacenados (y cómo usarlos). En todo caso, vas a tener que serenar tu apuro porque la cosa exige más esfuerzo del que parece a primera vista. Hay mucho que aprender y experimentar. Yo probé bastante hasta que pude conectar una aplicación boba que tenía esos dos componentes que te dije más un grid y un datasource en una pc en red a mi servidor. Cuando ví que en el grid aparecían tres o cuatro registros que había metido vía SQL, me emocioné hasta las lágrimas. Hoy, después de eso, avanzo más rápido. Lo difícil es entender cómo funciona el sistema y cómo se configura. Después aparecen otros problemas, pero es otra historia... Tu sistema ya anda.

No dudes que el esfuerzo vale la pena. Hay muchas ventajas en el sistema cliente/servidor. Es más seguro, el tráfico de red se reduce drásticamente por lo cual la aplicación debería andar más rápido, soportan muchísimos más registros con menos problemas, el SBD se ocupa él sólo de muchas cosas molestas (verificar integridad referencial, bloqueos, etc.). Además, una red puede tener una máquina muy buena (server) y varias mediocres (estaciones de trabajo clientes), y recargar el trabajo en el servidor. Los procedimientos almacenados hacen que el trabajo pesado lo haga esa máquina y devuelva el resultado listo o casi listo para mostrar al usuario. Hay nuevas variables a considerar: por ahí conviene llevar una selección de datos al cliente y usar la capacidad de procesamiento del cliente para obtener el producto final y liberar al servidor para que siga atendiendo otras peticiones, y otras conviene hacer todo en el servidor. Son matices que hacen más compleja la cosa y por lo cual opino que empieces por estudiar:
1) Parámetros técnicos de instalación y configuración de tu SBD (SQL Server). No sea cosa que cuando tengas varios registros en un sistema que funciona OK de golpe tengas un martes 13 (Máximo tamaño elegido para la BD, por ejemplo, que por defecto debería ser muy grande, no obstante). O usuarios concurrentes máximo (licencias?).
2) Información básica de lo que es una IP, un host, una red armada sobre Windows (en tu caso), etc. O sea, si deja de andar porque alguien metió mal un dedito... que sepas dónde buscar para hacerla andar mágicamente otra vez
3) Lenguaje SQL específico para tu SBD (Hay 3 mil tutoriales, escribí "tutorial de SQL" en Google, por ejemplo).
4) Componentes Delphi para accederlo (BDE, DBExpress,Zeos,etc.)

Lo demás, suponemos que conocés Delphi , si es con este lenguaje que pensás trabajar.

Si lo que te describo ya lo conocés más o menos y la duda es puntualmente sobre los procedimientos almacenados, se crean con CREATE PROCEDURE o lo que soporte tu SBD. La sintaxis incluye parámetros que tenés que pasarle para trabajar, y te devuelve un cursor resultado. Se llaman con el componente TStoredProc, o aún desde una sentencia SQL tipo SELECT, como si se tratara de una tabla más, si es que el BSD lo admite. Otra manera es si disponemos del comando SQL "EXECUTE" (SQL Server lo soporta, creo). Una vez más, hay que leer sobre el SBD que usamos y los componentes que disponemos para acceder.

Te puede servir en algo: http://www.iespana.es/canalhanoi/pro...n/sqlsever.htm
donde explica algo de esto para SQL Server.

Bueno, espero que te escriba pronto un moderador para que te informe y guíe de verdad.

Saludos!!
Responder Con Cita