Table.Field method

[Joakim Schramm]

> > 
> > Just a design question, is it a bad idea to have 1 table with many 
> > fields or better to split them up in several tables, I am mostly 
> > thinking of performance?
> 
> Valentina prefer tables with smaller number of fields.
> 
Any preferable max number 10, 20, 30 etc. to not significantly "loose" in
performace"?

> So if logically you can split values to group it can be good.
>  
> > I have to store almost 700 different values for 1 record, 
> values that 
> > is calculated and stored once but then only read. All this 
> is stored 
> > in a UDT (User Defined Type) structure, containg sub 
> structures and and arrays.
> 
> Hint: if you not index that values, even possible pack them 
> into BLOB as
> e.g.   Array of ints [200]
>  
Hm, not sure if that can be done in VB6 I program in, as for structures
there is a "technique" to use tmp file for Put/Get but as I need to have
dynamic arrays in some UDT's it doesn't work here. Not sure if it would work
and how to do it with a BLOB?

> 
> > As an example, I have 1 group of 8 different values stored 
> in an UDT 
> > and an
> > array(34) As UDT. So just this batch of values will make 
> 280 fields I 
> > one table.
> 
> Again, for arrays which keep values which you not need to 
> index you can use
>     FixedBinary     -- good for array of fixed size
>     VarBinary       -- good for array of var size
>     BLOB            -- good for array of unlimited size
> 
Again, not sure how to go about to store and read this back in a proper way
with VB6, doubt it's possible - at least not w/o an API I don't know about.
Been thinking of CopyMemory API but locate vars in a "funny" way.

Regards,
Joakim