number of columns in a table field

[Josh Mellicker]

I have been working on a database front end in Rev, and in most ways  
have been happier than any other solution I've worked in. It is fast  
and reliable.

To state the obvious, I miss some things about a dedicated database  
development environment like FileMaker, but I have been slowly  
developing writing a library of functions that are increasingly  
serving as an easy and powerful layer between:

  - a card with a scrolling group of individual groups of controls,  
each subgroup representing a record in the database

  - a remote MySQL database

For example, I have a function that populates a field or option menu  
with some text data from a series of records, then sets a custom prop  
of the control to a list of the database IDs, so when the user  
selects a line in the field of an option from the menu, the database  
ID of that record is immediately accessible, yet invisible to the user.

(I feel certain I am reinventing the wheel at every step!)

I realize this is an obvious and rudimentary example, but it would be  
cool if there were a whole bunch of these functions that were  
invisible to the developer.

I know Sarah and Trevor and many others have written stacks and  
libraries that I am gradually becoming aware of, and Rev even has a  
built-in Query Builder that I just either don't like or don't get,  
but I have not found the ideal solution for being able to whip  
together a multiuser shared data solution with several cards in about  
as much time, and in as intuitive a process as FileMaker... but  
superior to FileMaker in power and flexibility and multi-user  
options, where controls hook up to their corresponding database  
records invisibly, where things like record IDs and complex JOIN SQL  
syntax are mostly invisible to the developer.

So, to summarize all this rambling, it's clear a Rev library could be  
written that made 90% of the common things people need to do with a  
shared database easy and intuitive... and then jumping in to script  
the other 10% could be done by a specialist.

If anyone has done this already or wants to plan out a library  
everyone could contribute to, let me know!

:-)

On May 31, 2006, at 8:35 AM, Jonathan Lynch wrote:

>
> I have thought of another method, using only enough rows to be  
> visible in
> the table, and storing all the rest of the data in custom props -  
> then, when
> you scroll, it would actually just reassign the information in each  
> row.
> Such a thing would be tough to implement so that it actually looks  
> like
> normal scrolling, but I think it could be done.