TAdoDatasource

[miguel]

Hola:
Tengo este código para conectar a SQL Server
WITH OBJECT ::oAdoDS
:cConnect := "Provider=SQLOLEDB.1;Persist Security
Info=False;Initial Catalog=Pruebas;Data Source=192.168.1.5"
:cUser := "Usuario"
// :cPassword := "0000000"
:lconnected := .T.
END WITH
Si Descomento la linea ":cPassWord", todo funciona perfectamente, pero
así­ como está, sale la ventana de conexion, introduciendo en ella el
usuario y le password sale otra ventana de error. Adjunto ambas ventanas.
El mismo proceso con TOdbcDataSource el funcionamiento es correcto, con
la siguiente cadena de conexión.
:cConnect := "DRIVER=SQL Server; UID=Usuario; PWD=torsat;
SERVER=192.168.1.5;" Network=DBMSSOCN; DATABASE=Pruebas;"
La idea inicial serí­a que omitiendo el :cUser u :cPassWord, saliera la
ventana de conexión de Ado.
Gracias.
--

[ignacio]

Miguel,
Solucionado. Muchas gracias.
Un saludo,
--
Ignacio Ortiz de Zúñiga
http://www.xailer.com
"Miguel A. Torrellas" <miguel@torrellas.net> escribió en el mensaje
news:[email=453648a5@news.xailer.com...]453648a5@news.xailer.com...[/email]
> Hola:
>
> Tengo este código para conectar a SQL Server
>
> WITH OBJECT ::oAdoDS
> :cConnect := "Provider=SQLOLEDB.1;Persist Security
> Info=False;Initial Catalog=Pruebas;Data Source=192.168.1.5"
> :cUser := "Usuario"
> // :cPassword := "0000000"
> :lconnected := .T.
> END WITH
>
> Si Descomento la linea ":cPassWord", todo funciona perfectamente, pero
> así como está, sale la ventana de conexion, introduciendo en ella el
> usuario y le password sale otra ventana de error. Adjunto ambas ventanas.
>
> El mismo proceso con TOdbcDataSource el funcionamiento es correcto, con
> la siguiente cadena de conexión.
>
> :cConnect := "DRIVER=SQL Server; UID=Usuario; PWD=torsat;
> SERVER=192.168.1.5;" Network=DBMSSOCN; DATABASE=Pruebas;"
>
> La idea inicial sería que omitiendo el :cUser u :cPassWord, saliera la
> ventana de conexión de Ado.
>
> Gracias.
>

[miguel]

Hola:
Estoy cambiando uno de mis proyectos que conectaban a SQL Server a
traves de TOdbcDatasource a TAdoDataSource.
Antes los browses con alguna celda de la base de datos con valor NULL,
las mostraba en blanco, ahora muestra NIL. A mi personalmente me parece
mas correcto en blanco, al usuarios de nuestros programas la palabra NIL
les va a resultar una cosa rara.
Saludos. Miguel A. Torrellas
--

[ignacio]

Miguel,
Pero es más correcto poner NIL. Siempre puede uitlizar el evento
oCol:OnGetData para convertirlo a blancos cuando sea NIL.
Un saludo,
--
Ignacio Ortiz de Zúñiga
http://www.xailer.com
"Miguel A. Torrellas" <miguel@torrellas.net> escribió en el mensaje
news:[email=453c8872@news.xailer.com...]453c8872@news.xailer.com...[/email]
> Hola:
>
> Estoy cambiando uno de mis proyectos que conectaban a SQL Server a
> traves de TOdbcDatasource a TAdoDataSource.
>
> Antes los browses con alguna celda de la base de datos con valor NULL,
> las mostraba en blanco, ahora muestra NIL. A mi personalmente me parece
> mas correcto en blanco, al usuarios de nuestros programas la palabra NIL
> les va a resultar una cosa rara.
>
> Saludos. Miguel A. Torrellas
>
>

[miguel]

Cuestión criterios, pero si es mas correcto habrí­a que aplicar el mismo
a las dos tecnologí­as. Es mi opinión.
Ignacio Ortiz de Zúñiga escribió:
> Miguel,
>
> Pero es más correcto poner NIL. Siempre puede uitlizar el evento
> oCol:OnGetData para convertirlo a blancos cuando sea NIL.
>
> Un saludo,
>

[ignacio]

Miguel,
Efectivamente, lo que está mal es el antiguo ODBC. Desgraciadamente el motor
de ODBC se apoya en tablas temporales DBF que no soportan valores nulos, y
hacer la modificación supondría una perdida de velocidad que no creo esté
justificada. Además, en cuanto esté completamente terminado ADO se
desaconsejerá la utilización del driver ODBC directo y tan sólo se mantendrá
por compatibilidad hacia atras.
Un saludo,
--
Ignacio Ortiz de Zúñiga
http://www.xailer.com
"Miguel A. Torrellas" <miguel@torrellas.net> escribió en el mensaje
news:453c8fb4$[email=1@news.xailer.com...]1@news.xailer.com...[/email]
> Cuestión criterios, pero si es mas correcto habría que aplicar el mismo a
> las dos tecnologías. Es mi opinión.
>
>
>
> Ignacio Ortiz de Zúñiga escribió:
>> Miguel,
>>
>> Pero es más correcto poner NIL. Siempre puede uitlizar el evento
>> oCol:OnGetData para convertirlo a blancos cuando sea NIL.
>>
>> Un saludo,
>>

[miguel]

Entonces se debe interpretar que TDBEdit ha de poner tambien NIL. Me
pregunto.
Ignacio Ortiz de Zúñiga escribió:
> Miguel,
>
> Efectivamente, lo que está mal es el antiguo ODBC. Desgraciadamente el motor
> de ODBC se apoya en tablas temporales DBF que no soportan valores nulos, y
> hacer la modificación supondrí­a una perdida de velocidad que no creo esté
> justificada. Además, en cuanto esté completamente terminado ADO se
> desaconsejerá la utilización del driver ODBC directo y tan sólo se mantendrá
> por compatibilidad hacia atras.
>
> Un saludo,
>

[ignacio]

Miguel,
Si, así es. Y de hecho lo pone porque es realmente lo que vale.
Un saludo
--
Ignacio Ortiz de Zúñiga
http://www.xailer.com
"Miguel A. Torrellas" <miguel@torrellas.net> escribió en el mensaje
news:453c937f$[email=1@news.xailer.com...]1@news.xailer.com...[/email]
> Entonces se debe interpretar que TDBEdit ha de poner tambien NIL. Me
> pregunto.
>
> Ignacio Ortiz de Zúñiga escribió:
>> Miguel,
>>
>> Efectivamente, lo que está mal es el antiguo ODBC. Desgraciadamente el
>> motor de ODBC se apoya en tablas temporales DBF que no soportan valores
>> nulos, y hacer la modificación supondría una perdida de velocidad que no
>> creo esté justificada. Además, en cuanto esté completamente terminado ADO
>> se desaconsejerá la utilización del driver ODBC directo y tan sólo se
>> mantendrá por compatibilidad hacia atras.
>>
>> Un saludo,
>>

[miguel]

Ignacio
En TDBEditBtn pone blancos, TDBEMemo pone NIL, tendré que revisar todos.
Y sigo pensando que al usuario del programa esto no le va a agradar,
¿que eventos hay? en los campos de edición para eliminar este efecto,
para poder manejar este tema porque insisto que a mis usuarios no les va
a gustar nada este cambio y voy a necesitar cambiar todos los controles
uno a uno.
Perdona si insisto pero solo expongo mi opinión que no será la buena,
pero es la mí­a.
Ignacio Ortiz de Zúñiga escribió:
> Miguel,
>
> Si, así­ es. Y de hecho lo pone porque es realmente lo que vale.
>
> Un saludo
>

[ignacio]

Miguel,
Si algún control pone blancos será seguramente por su máscara.
No es normal editar un registro con valor nulo, e incluso, creo recordar que
otros entornos de desarrollo dan un error de ejecución al intentarlo.
En mi opinión es responsabilidad del programador evitar la posibilidad de
editar directamente un campo con valores nulos. No obstante acabo de
modificarlo para que lo pase a blancos SOLO cuando se intenta editar el
campo con nulos. Espero que sea suficiente y no tenga ningún efecto
colateral indeseable.
Un saludo,
--
Ignacio Ortiz de Zúñiga
http://www.xailer.com
"Miguel A. Torrellas" <miguel@torrellas.net> escribió en el mensaje
news:453c9e85$[email=1@news.xailer.com...]1@news.xailer.com...[/email]
> Ignacio
> En TDBEditBtn pone blancos, TDBEMemo pone NIL, tendré que revisar todos. Y
> sigo pensando que al usuario del programa esto no le va a agradar, ¿que
> eventos hay? en los campos de edición para eliminar este efecto, para
> poder manejar este tema porque insisto que a mis usuarios no les va a
> gustar nada este cambio y voy a necesitar cambiar todos los controles uno
> a uno.
>
> Perdona si insisto pero solo expongo mi opinión que no será la buena, pero
> es la mía.
>
>
> Ignacio Ortiz de Zúñiga escribió:
>> Miguel,
>>
>> Si, así es. Y de hecho lo pone porque es realmente lo que vale.
>>
>> Un saludo
>>

[ignacio]

Miguel,
No obstante, simpre puedes modificar tu tabla SQL para que no admita nulos y
ponga un valor defecto en los campos que no se editan.
Un saludo,
--
Ignacio Ortiz de Zúñiga
http://www.xailer.com
"Ignacio Ortiz de Zúñiga" <NoName@xailer.com> escribió en el mensaje
news:453ca536$[email=1@news.xailer.com...]1@news.xailer.com...[/email]
> Miguel,
>
> Si algún control pone blancos será seguramente por su máscara.
>
> No es normal editar un registro con valor nulo, e incluso, creo recordar
> que otros entornos de desarrollo dan un error de ejecución al intentarlo.
>
> En mi opinión es responsabilidad del programador evitar la posibilidad de
> editar directamente un campo con valores nulos. No obstante acabo de
> modificarlo para que lo pase a blancos SOLO cuando se intenta editar el
> campo con nulos. Espero que sea suficiente y no tenga ningún efecto
> colateral indeseable.
>
> Un saludo,
>
> --
> Ignacio Ortiz de Zúñiga
> http://www.xailer.com
> "Miguel A. Torrellas" <miguel@torrellas.net> escribió en el mensaje
> news:453c9e85$[email=1@news.xailer.com...]1@news.xailer.com...[/email]
>> Ignacio
>> En TDBEditBtn pone blancos, TDBEMemo pone NIL, tendré que revisar todos.
>> Y sigo pensando que al usuario del programa esto no le va a agradar, ¿que
>> eventos hay? en los campos de edición para eliminar este efecto, para
>> poder manejar este tema porque insisto que a mis usuarios no les va a
>> gustar nada este cambio y voy a necesitar cambiar todos los controles uno
>> a uno.
>>
>> Perdona si insisto pero solo expongo mi opinión que no será la buena,
>> pero es la mía.
>>
>>
>> Ignacio Ortiz de Zúñiga escribió:
>>> Miguel,
>>>
>>> Si, así es. Y de hecho lo pone porque es realmente lo que vale.
>>>
>>> Un saludo
>>>
>
>

[miguel]

Ignacio,
Ignacio Ortiz de Zúñiga escribió:
> Miguel,
>
> Si algún control pone blancos será seguramente por su máscara.
>
> No es normal editar un registro con valor nulo, e incluso, creo recordar que
> otros entornos de desarrollo dan un error de ejecución al intentarlo.
Si no es normal ¿por que razón? debo ser responsable de evitarlo, no
serí­a mas lógico que el propio sistema lo contemplara.
>
> En mi opinión es responsabilidad del programador evitar la posibilidad de
> editar directamente un campo con valores nulos. No obstante acabo de
> modificarlo para que lo pase a blancos SOLO cuando se intenta editar el
> campo con nulos. Espero que sea suficiente y no tenga ningún efecto
> colateral indeseable.
Seguro que hay alguna razón poderosa para que ahora se muestren los NIL
aunque yo no la entienda, es mi opinión contra la de los maestros, con
lo cual seguro que el que está equivocado soy yo, pero me gustarí­a
conocer cual es esa razón o que finalidad tiene.
>
> Un saludo,
>

[miguel]

Ignacio Ortiz de Zúñiga escribió:
> Miguel,
>
> No obstante, simpre puedes modificar tu tabla SQL para que no admita nulos y
> ponga un valor defecto en los campos que no se editan.
Si, de acuerdo, pero no siempre hemos de utilizar tablas diseñadas por
nosotros. También puedo poner en los select "isnull(...., '') hay varias
maneras de evitarlo, pero me sigo diciendo que por que evitar siempre lo
que no tiene ninguna utilidad para el usuario final que en definitiva
es de lo que se trata. Un usuario no entiende ni tiene porque entender
que es NULL, NIL, .T., .F. etc. etc.
Seria mejor que el sistema lo contemple directamente y si queremos rizar
el rizo un Propiedad en DataSet.
No obstante gracias por tu tiempo y tu consideración al cambiarlo en los
controles de edición.
Me gustarí­a hacer un llamamiento a opiniones de otros "Xaileros".
>
> Un saludo,
>