Problemas con Strict off

Ese problema tenímos por acá Juan. Nunca, nunca, nunca mandes cadenas hacia
SQL Server, esperando que él haga la conversión hacia DateTime. En tus stored
procedures, si el parámetro a recibir es DateTime, haz que el parámetro sea
un DateTime explícitamente. Así mismo, prepara el SQLParameter de ADO.Net
para que sea de tipo DateTime. Es la única forma de asegurar que el framework
y SQL Server hablen el mismo lenguaje.

Saludos.

Julio Casal
.Net Solution Developer
MCAD
Grupo Lebed


"Juan Melas" wrote:

Al parecer el problema lo estoy teniendo con sql server al realizar la
conversión ímplicata de las fechas contenidas en la cadena, ahora tambien
falla en mi máquina, lo curioso es que hasta ayer funcionaba perfectamente,
no se si será alguna configuración de sql server o deberé cambiar la
consulta con los campos datetime.

"Julio Casal" escribió en el mensaje
news:
> Hola Juan. Es muy buena práctica el usar Option Strict On, ya que eso te
> previene de una serie de problemas más adelante cuando quieras darle
> mantenimiento ó cuando quieras depurar tu aplicación. Son increíbles la
> cantidad de problemas que surgen cuando no lo activas, te lo digo por
> experiencia.
>
> Para resolver tu problema en particular, simplemente haz el Cast adecuado
> usando el método Parse correspondiente. Algo así:
>
> Dim fecha As DateTime = Date.Parse(cadena)
>
> Espero haber podido ayudarte.
>
> Saludos.
> Julio Casal
> .Net Solution Developer
> MCAD
> Grupo Lebed
>
>
> "Juan Melas" wrote:
>
>> Leonardo: El error salta al ejectuar una funcion que carga un dataset a
>> la
>> que mando como parámetro una cadena con la instrucción sql en mi máquina
>> funciona perfecto pero al pasarlo a otra máquina tira el error , la fecha
>> la
>> tomo de un Date Time Picker , en principio armaba la cadena tomando el
>> valor
>> que me daba el datetimepicker, siguiendo todos los consejos que he leido
>> puse la opción Strict a On y me dió gran cantidad de errores de
>> asignación
>> de variables que estoy corrigiendo en todas las capas de la aplicación,
>> creo
>> que tendré que modificar la lógica y usar parámetros en lugar de
>> concatenar
>> toda la instrucción como una cadena.
>>
>> "Leonardo Azpurua [mvp vb]" <l e o n a r d o (arroba) m v p s (punto) o r
>> g>
>> escribió en el mensaje news:eMStkX%
>> >
>> > "Ivanhoe" escribió en el mensaje
>> > news:
>> >> de hecho tu aplicacion la debiste desarrollar con string on
>> >> para evitar malas mañas.
>> >>
>> >> para activala por default on,...en :
>> >>
>> >> Project -> Properties -> Common Properties -> Buid
>> >
>> > Hola, Ivanhoe:
>> >
>> > A pesar de todas las recomendaciones, no hay manera de que yo le vea la
>> > ventaja al Strict On.
>> >
>> > Es cierto que detecta algunos errores en tiempo de compilación, que de
>> > lo
>> > contrario te iban a dar problemas en tiempo de ejecución.
>> >
>> > Pero el precio que hay que pagar por esa seguridad adicional, es
>> > complicar
>> > (si es que no impide por completo) el uso del Late Binding, una
>> > característica sin la cual se me hace muy difícil vivir (sé que el uso
>> > de
>> > interfaces te da casi la misma flexibilidad que no usar Option Strict,
>> > de
>> > manera "controlada", pero si sobreviví a quince años de trabajo con
>> > "C",
>> > creo que puedo prescindir de esa pequeña ayuda, a cambio de escribir
>> > muchísimo menos).
>> >
>> > Por otra parte, si el problema que tiene Juan es derivado de la
>> > configuracion regional (y esa es la impresión que me da), tener Strict
>> > On
>> > u Off no va a hacer ninguna diferencia.
>> >
>> >> "Juan Melas" wrote in message
>> >> news:
>> >>> Desarrolle una aplicación con la opción Strict off, en mi maquina
>> >>> funciona
>> >>> bien, al copiarla a otra máquina me marca "error de sintaxis al
>> >>> convertir
>> >>> una cadena de caracteres a datetime".
>> >
>> > Hola, Juan:
>> >
>> > Es probable que el problema surja de alguna diferencia en la
>> > configuración
>> > regional entre tu equipo de desarrollo y el equipo donde te da el error
>> > de
>> > sintaxis.
>> >
>> > Si utilizas constantes para representar fechas dentro de tu código, es
>> > conveniente que las expreses siempre como fechas (#mm-dd-yyyy#). Y si
>> > estás recibiendo una fecha en un TextBox, lo más sensato sería que
>> > validaras la corrección del formato en el evento Validate del control,
>> > y
>> > que la convirtieras a fecha (mediante CDate o mejor con Date.Parse) y
>> > la
>> > almacenes en una variable del tipo correcto antes de realizar ningun
>> > proceso con ella.
>> >
>> > Aunque no soy fanático del Option Strict, sí creo que las variables que
>> > se
>> > usarán para almacenar datos deben ser del tipo de dato corresponiente:
>> > te
>> > ahorras muchísimos problemas.
>> >
>> > Salud!
>> >
>> >
>>
>>
>>

"Julio Casal" escribió en el mensaje
news:

Para resolver tu problema en particular, simplemente haz el Cast adecuado
usando el método Parse correspondiente. Algo así:

Dim fecha As DateTime = Date.Parse(cadena)

Pero eso sí: encierra el "Cast" dentro de un bloque Try/Catch, porque como
<cadena> traiga "Pepe" no va a haber Option Strict que te salve de una
excepcion.

Para incluir fechas en sentencias T-SQL, uso la construcción "{d
'yyyy-mm-dd'}", aunque 'yyyy-mm-dd' tambien funciona siempre.

Entiendo que el uso de Option Strict previene una cantidad de problemas
relativamente frecuentes. Y que si se programa de una manera disciplinada no
representa en modo alguno una limitación.

Si tienes un procedimiento que opera sobre instancias de una de tres clases
Ca, Cb y Cc, en lugar de declarar el procedimiento como ElProc(arg As
Object), corriendo el riesgo de que alguna vez lo llames con un argumento
incorrecto, lo que haces es que creas una interfaz que presente los miembros
comunes de Ca, Cb y Cc tal como se usan en ElProc, haces que las tres clases
implementen esa interfaz (Iabc) y redeclaras el metodo como ElProc(arg As
Iabc). Es un poco de trabajo adicional, pero de verdad que ganas mucho en
seguridad del código y obtienes varios beneficios al momento de codificar,
sobre todo la ayuda de Intellisense, que no es poca cosa cuando tienes que
escribir funciones largas y complejas.

El punto es que usar o no usar Option Strict no tiene nada que ver con
problemas como el que nos ocupa ahora (sintaxis al asignar una cadena a una
fecha). Da igual escribir (asumiendo que miFecha esta declarada As Date)
miFecha = CType(laCadena, Date) -con Option Strict- que miFecha =
laCadena -sin Option Strict. Si laCadena representa una fecha valida,
funcionará; de lo contrario, fallará en ambos casos.

No soy un detractor de Option Strict: simplemente tengo demasiado tiempo
trabajando sin ese recurso (ni VB6 ni "C", que son los lenguajes que más he
trabajado lo tenían) y el cambio de actitud de mi parte, más los cambios
requeridos en el código heredado están fuera de mis posibilidades (y son
innecesarios en mis circunstancias actuales). Pero tampoco es cosa de
presentarlo como una panacea: si se validan los datos recibidos, da igual
usarlo o no; y si no se validan, tambien.

Salud!

No soy un detractor de Option Strict: simplemente tengo demasiado
tiempo trabajando sin ese recurso (ni VB6 ni "C", que son los
lenguajes que más he trabajado lo tenían) y

Pero en C el Option Strict On, aunque no existe, siempre esta activo!

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo
http://mvp.support.microsoft.com/pr...4EF5A4191C

"Eduardo A. Morcillo [MS MVP VB]" <emorcillo .AT. mvps.org> escribió en el
mensaje news:

No soy un detractor de Option Strict: simplemente tengo demasiado
tiempo trabajando sin ese recurso (ni VB6 ni "C", que son los
lenguajes que más he trabajado lo tenían) y

Pero en C el Option Strict On, aunque no existe, siempre esta activo!

Hola, Eduardo:

No se si en C++ (nunca trabajé con él), pero en el viejo "C", no hay nada de
eso.

Puedes declarar una función como int laFuncion(void *arg), y pasarle un
apuntador a lo que se te ocurra.

Si no usas prototipos, y a una función declarada como void otraFuncion(int
*a) le pasas un apuntador a un double, vas a tener un resultado impredecible
(a menos que lo que quieres hacer sea exacatmente eso) pero la acepta. Si
usas el prototipo el compilador detectará el error (no recuerdo si lo marca
como error o como advertencia).

Luego tienes conversiones implícitas entre tipos numéricos:
int a;
double b;
b = a; a = b;
no causa ni la mas leve queja del compilador.

Igual tienes conversiones implícitas en los argumentos de las funciones. Si
dentro del ambito de visibilidad del prototipo:
int miOtraFuncion(double);
y dadas las siguientes declaraciones:
double a,b;
ejecutas
a = miOtraFuncion(b);
el compilador se ocupa de las conversiones de b a int y del resultado a
double.

Nada de eso se parece a Option Strict On.

Salud!

No se si en C++ (nunca trabajé con él), pero en el viejo "C", no hay
nada de eso.

No hay nada parecido en ninguna de las variedades de C. Lo que quise decir
es que en C es como si siempre tuvieras Option Strict On ya que debes hacer
conversiones desde y hacia "strings" explicitamente y las conversiones con
perdida de precision generan advertencias. En cuanto a lo de las funciones
el compilador no da error si no encuentra el prototipo, pero genera una
advertencia. Si con Strict Off se generaran advertencias no seria tan
problematico y seria mas facil saber en que puntos es mas probable que pueda
ocurrir un error. Creo que es mucho mejor tener Strict On y decirle
explicitamente al compilador tus intenciones con el codigo (aunque se
escriba un poco mas) que dejar que el compilador haga su interpretacion.

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo
http://mvp.support.microsoft.com/pr...4EF5A4191C