Many Cards Versus One Card and a List Field

[Luis]

Anyone mention OpenBase (www.openbase.com)? 'Similar' to FM in  
certain aspects although I've found it more performant.
The OpenBase Forms might be an alternative reporting tool to look at.

The coolest EPOS I've seen uses it as a back end.

Cheers,

Luis.



On 15 Jan 2008, at 08:54, Randall Lee Reetz wrote:

> Does rev offer a table object?
>
> -----Original Message-----
> From: "Peter Alcibiades" <palcibiades-first at yahoo.co.uk>
> To: "How to use Revolution" <use-revolution at lists.runrev.com>
> Sent: 1/15/2008 12:11 AM
> Subject: Many Cards Versus One Card and a List Field
>
> Maybe I don't understand the question (does happen!) but isn't the  
> answer
> something like this.
>
> 1)  Once data storage gets serious, more than a few thousand  
> records, Rev
> alone is not what to do it in.  If you want to do the rest of the  
> app in Rev,
> you have to add a real database.  This means sqlite, mysql (if you  
> need multi
> user and networked), Valentina, whatever.
>
> The issue is not one card versus many, the issue is tab delimited  
> fields
> versus real databases.
>
> 2)  If data storage retrieval and reports is the primary or only  
> need, its
> incredibly much quicker to do that sort of thing to some level in  
> Filemaker,
> but it may not come for your OS and has other limitations.  But you  
> do get
> point and click relational database and report construction.
>
> This is a real issue about Rev + sqlite, but its also an issue about
> alternatives to Rev + sqlite.
>
> 3)  Even if you can live with tab delimited files for storage,  
> getting reports
> out of them in Rev is not much fun  So you have to add Quartam.  Or  
> Perl or
> Awk.  This too is much easier and quicker in FM.  But the same  
> comment applies
> to the alternatives to Rev.
>
> Is there a gui package  (except the database packages with end user
> pretensions like FM) that does data storage and retrieval and  
> reporting much
> better than Rev?  Most seem to be a lot worse.  Python for  
> instance, I think
> you have to use a real database for just about any storage.   
> Nothing is
> perfect.
>
> This is my own case:  15-20k records of sales during the fiscal  
> year.  I
> accumulate them (with some trepidation) into an external tab  
> delimited text
> file.  Then we need to go through and extract sales by product by  
> month for
> some 200+ items.  After a prolonged meditation on switch, if and  
> repeat, and
> the prospect of creating a 200 x 12 matrix of fields with each one
> individually named and scripted, I broke out "Effective Awk  
> Programming".
>
> Its like reaching for a plane, after trying to get a smooth finish  
> with a
> chisel.  But chisels have their uses too, and are often the right  
> tool for
> the job.  Don't try doing a mortise with a plane!
>
> Well, please correct if this is not right.
>
>
> Peter
>
>
>
>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>