On Jul 25, 2013, at 10:45 AM, Mike Kerner wrote:
> LC's libraries need the ID so they know what you're asking them for after
> you've opened the DB. I just use globals. You can use a global with
> multiple lines, or an array with multiple elements, if you are going to
> have multiple DB's open.
I definitely wouldn't hard code the DBID! Just go with Mike's suggestion
and write some general purpose handlers that actually issue the LC db calls
and put them somewhere where they're always callable from anywhere else in
your stack (main stack script for example) If you do that, you don;t even
LC's libraries need the ID so they know what you're asking them for after
you've opened the DB. I just use globals. You can use a global with
multiple lines, or an array with multiple elements, if you are going to
have multiple DB's open. I THINK that the ID's are sequential and "unique"
per lau
Hi Mike
Thanks for the reply, it seems I can do less :-)
I got into the habit of doing it that way when I first experimented with
sqlite and DBLib and noticed that I get a new DBID everytime I reopen the
stack.
So I basically could just set the global to 1 and this works, as long as I
just use one
I think you are overthinking this.
IMHO, globals are far more convenient for the DBID. The DBID does not
really expire, especially for SQLite, where you are not connecting to a
server. When you close your stack or . The only time the DBID is going to
be different is if you open different DB's i
Hi all,
I am working on a project with a SQLite DB and I'm wondering if there is an
improvement to the following:
On preOpenStack I connect to the database and store the connection ID in a
custom property on the main stack.
In whatever command I write or execute where I use any sql command to r
