Interesting problem comparing strings with integer values...

[Chris Spencer]

	To quote a wise grey-beard in my company: "If it were easy, they
wouldn't pay us to do this."
	Unfortuately, we can't rely on stored procedures or built-in functions
of databases because we're working through a "unified layer" that will
eventually support Oracle, Informix, MS SQL Server, mySQL, postgre, DB2, etc...
	So as you can see, with us supporting so many different database
engines, relying on special features of any engine just won't fly.  Heh.
	One upshot of this is that I'm learning more than I *ever* wanted to
know about relational databases and syntax oddities of different SQL
implementations. :)

(OBONTOPIC) I'd be scared to everloving DEATH of doing this project in any
language other than Python.  Introspection and self-modifying code are the two
features that have made this project even remotely possible.

Chris.

On Wed, 15 Jan 2003 20:58:48 -0800, Dennis Lee Bieber <wlfraed at ix.netcom.com>
wrote:
>> As I mentioned in my first post, while the above SQL statement would
>> be incorrect, the below SQL code WOULD.
>> 
>> select blah from table where value>"00000999" and value<"00003432";
>>
>        According to my books, PostgreSQL and MySQL support:
>
>select blah from table where
>LPAD(value, 20, "0") > LPAD("999", 20, "0")
>
>assuming "value" is a string type and the 20 is an arbitrary result 
>width.
>
>        You may be attacking this from the wrong end -- see what functions are 
>available within the database SQL itself to support this. If you have 
>stored procedure capability, it may also be of help if you can define a 
>stored procedure function (I'm weak on what can be done with stored 
>procedures) accessible from within SQL statements.