V4RB - Retrieving Aggregate Function Values from Cursor

[Fitzbew at aol.com]

In a message dated 5/19/03 3:03:38 AM, sunshine at public.kherson.ua writes:


> on 5/19/03 6:01 AM, Fitzbew at aol.com at Fitzbew at aol.com wrote:
> 
> Hi Fitzbew,
> 
> > I am having trouble retrieving a MIN() value from a cursor (using V4RB 
> 1.9.7,
> > RB 4.5.2).  
> >
> > I have a String field in a database (I have verified the database values 
> are
> > correctly populated) that is populated with 'YYYY' values (1995, 
> 1996...).
> > Each value can occur multiple times. I am running this query:
> >
> > rstDB = dbAvx.SqlSelect("select DISTINCT Min(Date_from_YYYY) from
> > mainrecords")
> > (Excluding DISTINCT has no effect on the result.)
> 
> DISTINCT is not needed because Min returns one raw.
> 
> > The query returns a cursor with 1 record, however I have not been able to
> > retrieve the field value.
> >
> > This is how it was suggested to me to retrieve the value from the 
> recordset:
> >
> > varStr = rstDB.StringField(1).Value
> >
> > But using this method, varStr is not populated correctly. The resulting
> > varType of the varStr variable is String(8), but it is zero-length.    It 
> is
> > not Null.
> >
> > What am I doing wrong?
> 
> 
> You mean varStr has type VARIANT ?
> Try
>         dim vaStr as String.
> 
> All rest looks correct.
> Hmm, please look into _TEST example in V4RB archive.
> Find here tests on aggregate functions.
> May be you will find difference.
> 

Ruslan, 

Yes, varStr is Dim'd as a Variant.   DISTINCT was just a test.   I have also 
tried String and Integer variables, they don't work either.

> The same syntax works fine on the Long fields in my database (after changing 
> rstDB.StringField(1).Value to rstDB.LongField(1).Value). 
> 
I think that Min() just doesn't work with String fields.   The tests in the 
archive work great, but they appear to just be using numeric-type fields.

I can work around this ok, it's just going to be perplexing to any poor soul 
who has to look at my code in the future.

Thanks,
Fitzbew   
>