I usually use the old table field to hold database data on hidden cards, then grab the data from that to populate a datagrid the user sees.
The reason for using a field instead of a custom prop is that it's easier during development to see the data. I have handlers that will find and update data in tab delimited fields. If it's a huge dataset a custom prop is faster but usually it's small so the speed loss is a non issue. Cheers, Josh On Sep 17, 2010, at 4:08 PM, Andrew Kluthe <[email protected]> wrote: > > Hmmm, the data coming in is from a mySQL database and I have 3 sets of data. > Live data, update data, and Added data. > > Each of these is held in a datagrid simply for the ease at which it can be > turned from an array into tab delimited text that can be stored in a > flatfile as backup and the ability to search the through the data using the > datagrid API. > > The program works offline most of the time and at the end of the day gets > synced with the database. > > What do you suggest? This datagrid thing leads to so much overhead in that I > have to initialize it on the hidden cards before opening the program. > > Would you recommend I just write search & export functions for a custom > property? > > > -- > View this message in context: > http://runtime-revolution.278305.n4.nabble.com/DataGrid-Optimization-question-tp2544336p2544558.html > Sent from the Revolution - User mailing list archive at Nabble.com. > _______________________________________________ > use-revolution mailing list > [email protected] > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
