On Thu, Jul 25, 2013 at 11:43 AM, Mike Kerner wrote:
> Then what you might want to do is either use ODBC or your own method to
> mirror the remote db locally. Then the rest of your code stays the same
> and if the remote issue is resolved, you're grinning.
I'm actually developing my own, with qu
Then what you might want to do is either use ODBC or your own method to
mirror the remote db locally. Then the rest of your code stays the same
and if the remote issue is resolved, you're grinning.
On Thu, Jul 25, 2013 at 1:43 PM, Dr. Hawkins wrote:
> On Thu, Jul 25, 2013 at 9:52 AM, Mike Kern
On Thu, Jul 25, 2013 at 9:52 AM, Mike Kerner wrote:
> I would pick the method that's the easiest to implement and try it, first.
I initially did that--then changed to the array, as remote db access
turned out to have expensive latency.
So I have the remote DB, and also need a local cache of that
I would pick the method that's the easiest to implement and try it, first.
I would rather just access the DB instead of trying to load everything into
containers, so I indexed the relevant fields, and have found that even for
tens-of-thousands of records, doing a compound LIKE (with wildcards) quer
Dr. Hawkins wrote:
Searching through the archives, I found what would have been my next
question. The answer being that using ":memory:" as the filename
opens an sqlite database in memory rather than disk.
That said, has anyone ever looked into the relative performance of
caching data into two-
Searching through the archives, I found what would have been my next
question. The answer being that using ":memory:" as the filename
opens an sqlite database in memory rather than disk.
That said, has anyone ever looked into the relative performance of
caching data into two-dimensional arrays, a
