SoloCodigo

Hola....
     Mira, no te compliques mucho... mejor puedes transformar ese digito en un string, es decir con un
     Integer.toString(253)
esta funcion devolveria una cadena de caracteres... entonces... con esa cadena si puedes acceder facilmente a cada uno de los digitos.. que se yo, podria ser con un <CharAt> ese caracter puedes luego pasarlo a se un integer para podelo comparar con otro numero cualquiera....

Me entiendes??? si no entonces avisame!!! ahi esta mi direccion.. en el link de msn

Un vistazo al Visual Basic .NET y su relación con el .NET FrameWork

El entorno de desarrollo de Visual Basic.NET, trabaja bajo el .Net FrameWork, que es la plataforma sobre la cual trabajan todos las herramientas de desarrollo .NET, ya sea C#.NET, C++.NET, VB.NET, entre muchas otros.
   Algo importante a tomar en cuenta al utilizar no solo Visual Basic.NET, sino todas las herramientas que trabajan bajo el .NET FrameWork es que todos son ejecutados bajo el CLR (Common Language RunTime), además de existir
Un lenguaje, el IL (Intermediate Lenguage), que de hecho es el único lenguaje que reconoce el CLR. Todos los lenguajes compilan su código fuente al lenguaje intermedio (gracias al CLR Jut-In-Tme Compiler ) para después ser procesador por el CLR. (Este ultimo a su vez componente del .NET FrameWork)
   Una gran diferencia con Visual Basic 6.0 es la nueva concepción de OOP (Programación orientada a objetos) que adoptó Microsoft, donde ahora se pueden utilizar explícitamente los constructores, la herencia, creación de interfaces, eventos, sobrecargas, entre muchas otras cosas.
   Al estar todas estas herramientas bajo el .NET FrameWork existe una gran compatibilidad entre lenguajes, es decir, se puede utilizar librerías de C# perfectamente en VB.NET con solo llamar la referencia.
   Existe un CLS (Common Language Specifications) que se encarga de mantener una cierta compatibilidad entre los lenguajes. Aunque no es tan perfecto, Ej. C#.NET es KeySe... bueno, diferencia las mayúsculas de las minúsculas, en cambio VB.NET no, al llamar a una librería C#, que tenga dos métodos con el mismo nombre pero uno en Mayúscula y otro en minúscula (Es muy difícil que en un caso practico se dé, pero eso no justifica el que se de) VB.NET intentara sobre cargar este método, a pesar que para C# son dos métodos completamente distintos, es más, en el menú que se despliega cuando se presiona Ctrl+Space ese método solo se muestra una vez, y cuando es seleccionado lanza un error "Overload resolution failed".
   Otra ventaja de VB.NET es que no este amarrado al sistema operativo, es más, ni siquiera a la plataforma, este último pues existe un FrameWork especialmente hecho para ejecutar Smart Device Aplications (Pocket PC, Windows CE, y otros). Además .NET FrameWork no deja de lado la compatibilidad con otras tecnologías como lo es COM.
Con .NET FrameWork se termino el Infierno de los DLLs (DLL-Hell) ya que entran en juego los assemblys, cuya definición envuelve muchas cosas,  pero una sencilla y muy especifica seria que es un PE (Portable Ejecutable), con Metadata, y un archivo manifiesto que lo auto describen, bueno vienen siendo los DLLs o ejecutables creados con el .NET FrameWork, en el caso de los DLLs ya no es necesario registrarlos como en COM, hay dos formas de utilizar estos assemblys: privados o públicos, los privados seria tenerlos en el dominio de cada aplicación,  y los públicos serian globales, como por ejemplo el FCL (FrameWork Class Library).
   Además, no se debe dejar de lado que VB.NET al igual que todas las herramientas que trabajan con el FrameWork, están bajo un ambiente administrado, es decir, que el FrameWork provee el Garbage Collector, que es el que se encarga de administrar la memoria en tiempo de ejecución.

Dirán que todo lo anterior no tiene casi nada que ver con VB.NET específicamente, esto es, pues el .NET FrameWork envuelve todos los puntos de interés. Ejemplo de ello es que no se puede hablar de ADO.NET o ASP.NET para Visual Basic.NET, tendría que hablar de ADO.NET o ASP.NET para las herramientas de desarrollo .NET sin importar cual sea. Por eso si se sabe programar en C#.NET (por ejemplo) o viceversa no se te haría tan complicado aprender VB.NET.


Nota: Se aceptan criticas con respecto al presente documento!!

Hola... Segun lo que entiendo necesitas enviarle parametros a una consulta!!!
Si puedes enviarle los parametros desde la consulta con el caracter de signo de pregunta ( ? ).
 Ej.: "SELECT *
        FROM <la tabla>
        WHERE <columna> like ?"

y seguidamente al <PreparedStatement> (si estas usandolo) le envias el parametro con un setString o setInt  set<lo que haya>
        Ej.:
             stmt.setString(1,"HolaMundo");
donde setString(intParameterIndex, String texto)

....

Eso es lo que necesitabas??? o estoy perdido???

Hola... sinceramente no entiendo la primera parte de tu consulta... pero al final.. lo de los StoredProcedure si, un SPROC (StoreProcedure) no se puede colocar dentro de un SELECT, en ves de eso puedes colocar una FUNCTION que funciona casi igual, nada mas que en este caso si se podria llamar dentro del SELECT.