or custom reports they wanted.
Probably there is some reason for using sqlite that I'm not aware of?
Peter
--
View this message in context:
http://runtime-revolution.278305.n4.nabble.com/SQLite-data-storage-tp4662380p4662429.html
Sent from the Revolution - User mailing list archive
Thanks everyone for the feedback. Sounds like the general consensus is to use a
single table to store all the data, which is the direction I was leaning
anyway. I just wanted to make sure performance wouldn't take a hit, but it
sounds like that shouldn't be a problem.
Now I get to work on
Hi Chris,
Is the import a one-time task or an ongoing need? If the former and you
can export the spreadsheet data in csv format, there a number of tools that
will do the import for you.
On Fri, Mar 22, 2013 at 7:10 AM, Chris Sheffield cmsheffi...@icloud.comwrote:
Now I get to work on pulling
Hi Pete,
Just a one-time task. I'll export the sheets as you say, and then import them
using a tool that I've used for quite a while now. Time-consuming, but not too
bad.
Thanks,
Chris
On Mar 22, 2013, at 10:28 AM, Peter Haworth p...@lcsql.com wrote:
Hi Chris,
Is the import a one-time
.278305.n4.nabble.com/SQLite-data-storage-tp4662380p4662429.html
Sent from the Revolution - User mailing list archive at Nabble.com.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
of?
Peter
--
View this message in context:
http://runtime-revolution.278305.n4.nabble.com/SQLite-data-storage-tp4662380p4662429.html
Sent from the Revolution - User mailing list archive at Nabble.com.
___
use-livecode mailing list
use
I hope nobody minds that I ask this here. While it's not specifically about
LiveCode, the database I'm asking about will be used for a LiveCode app. :-)
I need some advice/pointers on how best to store some static read-only data
in a SQLite database. We're talking potentially thousands of
Chris-
Caveat: I know enough about databases to be dangerous, so if someone else chimes
in with conflicting information, ignore this.
I don't think you'll run into any problems with SQLite performance for what
you've got in mind. And anything beats Excel. Is there a reason the data is
separated
Hi Chris,
Difficult to answer without a little more information about your app. In
general, I wouldn't worry about the number of records - thousands won't
be an issue for SQLite.
I'd say that if the columns are the same on each sheet, one table will
probably be the way to go - it's not usually a
Hi Chris
While not a SQLite guru, I have used it on and off at various times and would
probably recommend just having it all in 1 table. Any read-only queries will
just return you a record set which you can put in a container and do anything
with. SQLite is quick, you can add indices and
Chris Sheffield wrote:
I need some advice/pointers on how best to store some static
read-only data in a SQLite database. We're talking potentially
thousands of records.
Thousands isn't very much. Is that the total for all the sheets? If
so, while SQLite is a good solution, sometimes
Thousands is like zero in terms of a performance hit. I have an app on
iOS that has tens-of-thousands of records in it, and to say it's
instantaneous would be an injustice.
There are lots of things you can do to enhance performance (either
normalizing or denormalizing the data, adding indexes,
Especially when the data is conveniently within data-grid size
On Thu, Mar 21, 2013 at 11:13 AM, Richard Gaskin ambassa...@fourthworld.com
wrote:
Thousands isn't very much. Is that the total for all the sheets? If so,
while SQLite is a good solution, sometimes keeping things simple with
13 matches
Mail list logo
