Where to store database ID

[Mike Kerner]

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 launch of LC, not per time the stack is opened, but don't quote me on
that.  Jacque?


On Thu, Jul 25, 2013 at 12:34 PM, Pascal Lehner <tate83 at gmail.com> wrote:

> 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 DB? When using two different ones, would I just use 1 and 2?
>
> I figure since it is a local DB it does not require a unique key or
> something (which 1 or 2 are not really, anyways..).
>
> Best regards,
> Pascal
>
> On 25 July 2013 16:07, Mike Kerner <MikeKerner at roadrunner.com> wrote:
>
> > 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 in a different order.  If you
> > are only ever using 1 db, then the DBID will always be 1, but you still
> > have to tell LC to open the DB when you open the stack, obviously.
> >
> > What I, and probably most of us have done, is to write some DB functions
> > and handlers, so that I can pass the tables and columns that I want, and
> > the functions/handlers use the DBID and call the LC functions to actually
> > process the query.
> >
> > If you are using a function/handler to do your database interaction, then
> > it doesn't even matter how you have the DBID stored - in a field, a
> custom
> > property, a global, some array, or anything else, because the
> > function/handler will be the only place that needs it.
> >
> >
> > On Thu, Jul 25, 2013 at 10:56 AM, Pascal Lehner <tate83 at gmail.com>
> wrote:
> >
> > > 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
> > read
> > > or write data, I always have to get the connection ID from the custom
> > > property and put it in a local variable as the first thing of this
> > command.
> > > This means I repeat that "put custom variable in local variable" quite
> > > often..
> > >
> > > Is this the right way or would you probably store it once in a global
> or
> > > so? Also, when does this connection ID expire and I need a new one? How
> > can
> > > I recognise that before the DB returns an error?
> > >
> > > Cheers from foggy Edinbra..
> > >
> > > Pascal
> > > _______________________________________________
> > > use-livecode mailing list
> > > use-livecode at lists.runrev.com
> > > Please visit this url to subscribe, unsubscribe and manage your
> > > subscription preferences:
> > > http://lists.runrev.com/mailman/listinfo/use-livecode
> > >
> >
> >
> >
> > --
> > On the first day, God created the heavens and the Earth
> > On the second day, God created the oceans.
> > On the third day, God put the animals on hold for a few hours,
> >    and did a little diving.
> > And God said, "This is good."
> > _______________________________________________
> > use-livecode mailing list
> > use-livecode at lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."