Re: may be an actual bug.Revisited

[mikeh@minivend.com]

******    message to minivend-users from mikeh@minivend.com     ******

Quoting mediamob (mediamob@dnaco.net):
> 
> I have tried a few more tests just to narrow down the problem a bit more.
> For one, I corrected my HTML after Ryan Hertz' reminder. It didn't fix the
> sort, but better code is better code, and I am appreciative. Assume the
> code below has a ; after each &nbsp.
> 
> I have also tried numeric sorts on other fields ( new values for tf=) and
> do not get the server error. On the only other numeric field I use (time)
> the sort is even vaild. The only thing that sets it off is sorting on
> 0.
> 
> If there is no way to do this, I am soliciting workarounds - I have
> thought of two:
> 
> 1. A duplicate field in each record that matches the value of [code].
> Major Kludge which I would like to avoid.
> 
> 2. Manual sorting of products.asc so the "native" order is numeric on
> [code]. Preliminary tests seem to indicate that this order is preserved
> into the GDBM file, but I'd like confirmation before I start a manual sort
> on that assumption.
> 

I need to find out what is going on here. I test and test the sorting stuff,
but apparently when it gets out in the real world it doesn't do what
it does here.

I assume of course that you are using release MV3.12. I have received
similar reports from others (notably Jason McMullan) and have not been
able to reproduce the problem here, where everything I sort works and
makes sense. But he has found a fix that I will implement in MV3.14 (no,
I'm not superstitious but others might be 8-).  It is mostly a bug fix/doc
improvement release (for a change) and should be out by next week or
so. The only real feature addition is a global Database capability so you
can provide standard country/state/locale etc. databases without taking up
too many DB connections. BTW, this will allow persistent DBI connections,
which many have asked for. I still feel that connection overhead should
not be the worry of an application and should be handled in the DB server
daemon process; it should be smart enough to cache table opens itself...

-- 
Mike Heins                          http://www.minivend.com/  ___ 
                                    Internet Robotics        |_ _|____
Fast, reliable, cheap.              131 Willow Lane, Floor 2  | ||  _ \
Pick two and we'll talk.            Oxford, OH  45056         | || |_) |
 -- unknown                         <mikeh@minivend.com>     |___|  _ <
                                    513.523.7621 FAX 7501        |_| \_\
-
To unsubscribe from the list, DO NOT REPLY to this message.  Instead, send
email with 'UNSUBSCRIBE minivend-users' in the body to Majordomo@minivend.com.
Archive of past messages: http://www.minivend.com/minivend/minivend-list