Memory Resident Data 
Author Message
 Memory Resident Data

Hi there,

I'm pretty sure I already know the answer to this one, but I'm not gonna
take the risk of posting it in case I make a fool of myself - let's see what
you folks come up with first.

Say I want to load some data from a SQL Server ahead of time, so that when
my VB App starts up, the data (in this case, consisting of a number of
client-side, disconnected, read only ADO Recordsets) is already
memory-resident.

So.....when the client workstations boot in the morning, they go off to the
SQL Server and grab this data and it just sits in RAM, doing nothing until
my App starts. Then my APP can grab the data without having to do a trip to
the server.

How do I accomplish this? Do I use a VB ActiveX EXE, scheduled to run at
boot? Or do I build a service ?  What is the best design ?

 TIA!
--
Kind Regards,

Robert A. Ellis, MCSD
Software Developer



Wed, 28 Jul 2004 02:02:14 GMT  
 Memory Resident Data
I would not leave them memory resident, I would persist them to the hard
drive, and then your app can load them from their persisted state using the
Recordset.Open statement.  For instance:

    (to persist to xml file)
    objRec.Save strFileName, adPersistXML

    (to load from xml file)
    objRec.Open strFileName, , adOpenStatic, adLockBatchOptimistic,
adCmdFile

HTH-Jon


Quote:
> Hi there,

> I'm pretty sure I already know the answer to this one, but I'm not gonna
> take the risk of posting it in case I make a fool of myself - let's see
what
> you folks come up with first.

> Say I want to load some data from a SQL Server ahead of time, so that when
> my VB App starts up, the data (in this case, consisting of a number of
> client-side, disconnected, read only ADO Recordsets) is already
> memory-resident.

> So.....when the client workstations boot in the morning, they go off to
the
> SQL Server and grab this data and it just sits in RAM, doing nothing until
> my App starts. Then my APP can grab the data without having to do a trip
to
> the server.

> How do I accomplish this? Do I use a VB ActiveX EXE, scheduled to run at
> boot? Or do I build a service ?  What is the best design ?

>  TIA!
> --
> Kind Regards,

> Robert A. Ellis, MCSD
> Software Developer



Wed, 28 Jul 2004 02:38:50 GMT  
 Memory Resident Data
Yep, sure, that's how it is set up now and it works quite well. But we wanna
go *faster*.

--
Kind Regards,

Robert A. Ellis, MCSD
Software Developer


Quote:
> I would not leave them memory resident, I would persist them to the hard
> drive, and then your app can load them from their persisted state using
the
> Recordset.Open statement.  For instance:

>     (to persist to xml file)
>     objRec.Save strFileName, adPersistXML

>     (to load from xml file)
>     objRec.Open strFileName, , adOpenStatic, adLockBatchOptimistic,
> adCmdFile

> HTH-Jon



> > Hi there,

> > I'm pretty sure I already know the answer to this one, but I'm not gonna
> > take the risk of posting it in case I make a fool of myself - let's see
> what
> > you folks come up with first.

> > Say I want to load some data from a SQL Server ahead of time, so that
when
> > my VB App starts up, the data (in this case, consisting of a number of
> > client-side, disconnected, read only ADO Recordsets) is already
> > memory-resident.

> > So.....when the client workstations boot in the morning, they go off to
> the
> > SQL Server and grab this data and it just sits in RAM, doing nothing
until
> > my App starts. Then my APP can grab the data without having to do a trip
> to
> > the server.

> > How do I accomplish this? Do I use a VB ActiveX EXE, scheduled to run at
> > boot? Or do I build a service ?  What is the best design ?

> >  TIA!
> > --
> > Kind Regards,

> > Robert A. Ellis, MCSD
> > Software Developer



Wed, 28 Jul 2004 02:57:58 GMT  
 Memory Resident Data
Hmm... if you want to share data between processes -- 1) the ActiveX exe
process to load and maintain the recordsets, and 2) the application process
that will access the recordsets -- you'll need to develop some sort of
singleton pattern which is kind of tricky in VB.  Here is a page that talks
about this subject and offers a technique to "sort of" achieve this:

http://users.skynet.be/wvdd2/General_techniques/Singletons/singletons...

This page also contains links to a couple other pages discussing this topic.

HTH-Jon


Quote:
> Yep, sure, that's how it is set up now and it works quite well. But we
wanna
> go *faster*.

> --
> Kind Regards,

> Robert A. Ellis, MCSD
> Software Developer



> > I would not leave them memory resident, I would persist them to the hard
> > drive, and then your app can load them from their persisted state using
> the
> > Recordset.Open statement.  For instance:

> >     (to persist to xml file)
> >     objRec.Save strFileName, adPersistXML

> >     (to load from xml file)
> >     objRec.Open strFileName, , adOpenStatic, adLockBatchOptimistic,
> > adCmdFile

> > HTH-Jon



> > > Hi there,

> > > I'm pretty sure I already know the answer to this one, but I'm not
gonna
> > > take the risk of posting it in case I make a fool of myself - let's
see
> > what
> > > you folks come up with first.

> > > Say I want to load some data from a SQL Server ahead of time, so that
> when
> > > my VB App starts up, the data (in this case, consisting of a number of
> > > client-side, disconnected, read only ADO Recordsets) is already
> > > memory-resident.

> > > So.....when the client workstations boot in the morning, they go off
to
> > the
> > > SQL Server and grab this data and it just sits in RAM, doing nothing
> until
> > > my App starts. Then my APP can grab the data without having to do a
trip
> > to
> > > the server.

> > > How do I accomplish this? Do I use a VB ActiveX EXE, scheduled to run
at
> > > boot? Or do I build a service ?  What is the best design ?

> > >  TIA!
> > > --
> > > Kind Regards,

> > > Robert A. Ellis, MCSD
> > > Software Developer



Wed, 28 Jul 2004 03:15:02 GMT  
 Memory Resident Data
The ActiveX .exe loaded at boot sounds pretty straightforward to me, but if
you want the ultimate in speed...

This'll sound whacked at first, but it could be done. Since VB source files
are simple text files, you could create a server process that runs every
morning at 5, queries the database, and creates a VB source file that
hardcodes the values into arrays. Then it could kick off VB with the /make
argument to recompile the program each day and copy the .exe out to the
network where everyone runs it from. When the users run the app, it doesn't
have to load the values from disk and doesn't have to query the database;
all the data is already compiled into the program in the arrays.


Quote:
> Yep, sure, that's how it is set up now and it works quite well. But we
wanna
> go *faster*.

> --
> Kind Regards,

> Robert A. Ellis, MCSD
> Software Developer



> > I would not leave them memory resident, I would persist them to the hard
> > drive, and then your app can load them from their persisted state using
> the
> > Recordset.Open statement.  For instance:

> >     (to persist to xml file)
> >     objRec.Save strFileName, adPersistXML

> >     (to load from xml file)
> >     objRec.Open strFileName, , adOpenStatic, adLockBatchOptimistic,
> > adCmdFile

> > HTH-Jon



> > > Hi there,

> > > I'm pretty sure I already know the answer to this one, but I'm not
gonna
> > > take the risk of posting it in case I make a fool of myself - let's
see
> > what
> > > you folks come up with first.

> > > Say I want to load some data from a SQL Server ahead of time, so that
> when
> > > my VB App starts up, the data (in this case, consisting of a number of
> > > client-side, disconnected, read only ADO Recordsets) is already
> > > memory-resident.

> > > So.....when the client workstations boot in the morning, they go off
to
> > the
> > > SQL Server and grab this data and it just sits in RAM, doing nothing
> until
> > > my App starts. Then my APP can grab the data without having to do a
trip
> > to
> > > the server.

> > > How do I accomplish this? Do I use a VB ActiveX EXE, scheduled to run
at
> > > boot? Or do I build a service ?  What is the best design ?

> > >  TIA!
> > > --
> > > Kind Regards,

> > > Robert A. Ellis, MCSD
> > > Software Developer



Wed, 28 Jul 2004 03:23:01 GMT  
 Memory Resident Data
cool idea! mmmm.... how brave am i? maybe not that brave ,,,,,,

What about this EXE idea? The problem I have with it, is persisting it. That
means a timer, or a loaded form, or something, doesn't it?

--
Kind Regards,

Robert A. Ellis, MCSD
Software Developer


Quote:
> The ActiveX .exe loaded at boot sounds pretty straightforward to me, but
if
> you want the ultimate in speed...

> This'll sound whacked at first, but it could be done. Since VB source
files
> are simple text files, you could create a server process that runs every
> morning at 5, queries the database, and creates a VB source file that
> hardcodes the values into arrays. Then it could kick off VB with the /make
> argument to recompile the program each day and copy the .exe out to the
> network where everyone runs it from. When the users run the app, it
doesn't
> have to load the values from disk and doesn't have to query the database;
> all the data is already compiled into the program in the arrays.



> > Yep, sure, that's how it is set up now and it works quite well. But we
> wanna
> > go *faster*.

> > --
> > Kind Regards,

> > Robert A. Ellis, MCSD
> > Software Developer



> > > I would not leave them memory resident, I would persist them to the
hard
> > > drive, and then your app can load them from their persisted state
using
> > the
> > > Recordset.Open statement.  For instance:

> > >     (to persist to xml file)
> > >     objRec.Save strFileName, adPersistXML

> > >     (to load from xml file)
> > >     objRec.Open strFileName, , adOpenStatic, adLockBatchOptimistic,
> > > adCmdFile

> > > HTH-Jon



> > > > Hi there,

> > > > I'm pretty sure I already know the answer to this one, but I'm not
> gonna
> > > > take the risk of posting it in case I make a fool of myself - let's
> see
> > > what
> > > > you folks come up with first.

> > > > Say I want to load some data from a SQL Server ahead of time, so
that
> > when
> > > > my VB App starts up, the data (in this case, consisting of a number
of
> > > > client-side, disconnected, read only ADO Recordsets) is already
> > > > memory-resident.

> > > > So.....when the client workstations boot in the morning, they go off
> to
> > > the
> > > > SQL Server and grab this data and it just sits in RAM, doing nothing
> > until
> > > > my App starts. Then my APP can grab the data without having to do a
> trip
> > > to
> > > > the server.

> > > > How do I accomplish this? Do I use a VB ActiveX EXE, scheduled to
run
> at
> > > > boot? Or do I build a service ?  What is the best design ?

> > > >  TIA!
> > > > --
> > > > Kind Regards,

> > > > Robert A. Ellis, MCSD
> > > > Software Developer



Wed, 28 Jul 2004 03:31:26 GMT  
 Memory Resident Data
An ActiveX exe will stay resident if there is a loaded (but hidden) form.
Make sure you provide the means to unload the form (via a method on a public
object).  Sounds like a pretty fun project, actually.  I'd be interested to
know how it works out.

-Jon


Quote:
> cool idea! mmmm.... how brave am i? maybe not that brave ,,,,,,

> What about this EXE idea? The problem I have with it, is persisting it.
That
> means a timer, or a loaded form, or something, doesn't it?

> --
> Kind Regards,

> Robert A. Ellis, MCSD
> Software Developer



> > The ActiveX .exe loaded at boot sounds pretty straightforward to me, but
> if
> > you want the ultimate in speed...

> > This'll sound whacked at first, but it could be done. Since VB source
> files
> > are simple text files, you could create a server process that runs every
> > morning at 5, queries the database, and creates a VB source file that
> > hardcodes the values into arrays. Then it could kick off VB with the
/make
> > argument to recompile the program each day and copy the .exe out to the
> > network where everyone runs it from. When the users run the app, it
> doesn't
> > have to load the values from disk and doesn't have to query the
database;
> > all the data is already compiled into the program in the arrays.



> > > Yep, sure, that's how it is set up now and it works quite well. But we
> > wanna
> > > go *faster*.

> > > --
> > > Kind Regards,

> > > Robert A. Ellis, MCSD
> > > Software Developer



> > > > I would not leave them memory resident, I would persist them to the
> hard
> > > > drive, and then your app can load them from their persisted state
> using
> > > the
> > > > Recordset.Open statement.  For instance:

> > > >     (to persist to xml file)
> > > >     objRec.Save strFileName, adPersistXML

> > > >     (to load from xml file)
> > > >     objRec.Open strFileName, , adOpenStatic, adLockBatchOptimistic,
> > > > adCmdFile

> > > > HTH-Jon



> > > > > Hi there,

> > > > > I'm pretty sure I already know the answer to this one, but I'm not
> > gonna
> > > > > take the risk of posting it in case I make a fool of myself -
let's
> > see
> > > > what
> > > > > you folks come up with first.

> > > > > Say I want to load some data from a SQL Server ahead of time, so
> that
> > > when
> > > > > my VB App starts up, the data (in this case, consisting of a
number
> of
> > > > > client-side, disconnected, read only ADO Recordsets) is already
> > > > > memory-resident.

> > > > > So.....when the client workstations boot in the morning, they go
off
> > to
> > > > the
> > > > > SQL Server and grab this data and it just sits in RAM, doing
nothing
> > > until
> > > > > my App starts. Then my APP can grab the data without having to do
a
> > trip
> > > > to
> > > > > the server.

> > > > > How do I accomplish this? Do I use a VB ActiveX EXE, scheduled to
> run
> > at
> > > > > boot? Or do I build a service ?  What is the best design ?

> > > > >  TIA!
> > > > > --
> > > > > Kind Regards,

> > > > > Robert A. Ellis, MCSD
> > > > > Software Developer



Wed, 28 Jul 2004 03:45:20 GMT  
 Memory Resident Data
Will note your email address & let you know what transpires.
R.

--
--
Kind Regards,

Robert A. Ellis, MCSD
Software Developer


Quote:
> An ActiveX exe will stay resident if there is a loaded (but hidden) form.
> Make sure you provide the means to unload the form (via a method on a
public
> object).  Sounds like a pretty fun project, actually.  I'd be interested
to
> know how it works out.

> -Jon



> > cool idea! mmmm.... how brave am i? maybe not that brave ,,,,,,

> > What about this EXE idea? The problem I have with it, is persisting it.
> That
> > means a timer, or a loaded form, or something, doesn't it?

> > --
> > Kind Regards,

> > Robert A. Ellis, MCSD
> > Software Developer



> > > The ActiveX .exe loaded at boot sounds pretty straightforward to me,
but
> > if
> > > you want the ultimate in speed...

> > > This'll sound whacked at first, but it could be done. Since VB source
> > files
> > > are simple text files, you could create a server process that runs
every
> > > morning at 5, queries the database, and creates a VB source file that
> > > hardcodes the values into arrays. Then it could kick off VB with the
> /make
> > > argument to recompile the program each day and copy the .exe out to
the
> > > network where everyone runs it from. When the users run the app, it
> > doesn't
> > > have to load the values from disk and doesn't have to query the
> database;
> > > all the data is already compiled into the program in the arrays.



> > > > Yep, sure, that's how it is set up now and it works quite well. But
we
> > > wanna
> > > > go *faster*.

> > > > --
> > > > Kind Regards,

> > > > Robert A. Ellis, MCSD
> > > > Software Developer



> > > > > I would not leave them memory resident, I would persist them to
the
> > hard
> > > > > drive, and then your app can load them from their persisted state
> > using
> > > > the
> > > > > Recordset.Open statement.  For instance:

> > > > >     (to persist to xml file)
> > > > >     objRec.Save strFileName, adPersistXML

> > > > >     (to load from xml file)
> > > > >     objRec.Open strFileName, , adOpenStatic,

adLockBatchOptimistic,

- Show quoted text -

Quote:
> > > > > adCmdFile

> > > > > HTH-Jon



> > > > > > Hi there,

> > > > > > I'm pretty sure I already know the answer to this one, but I'm
not
> > > gonna
> > > > > > take the risk of posting it in case I make a fool of myself -
> let's
> > > see
> > > > > what
> > > > > > you folks come up with first.

> > > > > > Say I want to load some data from a SQL Server ahead of time, so
> > that
> > > > when
> > > > > > my VB App starts up, the data (in this case, consisting of a
> number
> > of
> > > > > > client-side, disconnected, read only ADO Recordsets) is already
> > > > > > memory-resident.

> > > > > > So.....when the client workstations boot in the morning, they go
> off
> > > to
> > > > > the
> > > > > > SQL Server and grab this data and it just sits in RAM, doing
> nothing
> > > > until
> > > > > > my App starts. Then my APP can grab the data without having to
do
> a
> > > trip
> > > > > to
> > > > > > the server.

> > > > > > How do I accomplish this? Do I use a VB ActiveX EXE, scheduled
to
> > run
> > > at
> > > > > > boot? Or do I build a service ?  What is the best design ?

> > > > > >  TIA!
> > > > > > --
> > > > > > Kind Regards,

> > > > > > Robert A. Ellis, MCSD
> > > > > > Software Developer



Wed, 28 Jul 2004 03:51:44 GMT  
 Memory Resident Data
Or (I'm pretty sure) if it's busy doing something. This was a response I
wrote to someone doing network work, but I think it can apply here as well:

--------------------------

Do something like this:

    Private Declare Function WaitMessage Lib "User32" () As Long
    Private m_bDone As Boolean

    Public Sub Main()

        m_bDone = False
        Call OpenSocket()

        While Not m_bDone
            WaitMessage
            DoEvents
        Wend

        Call CloseSocket()

    End Sub

If you're planning on the app staying up forever (until reboot), s{*filter*}the
m_bDone flag and just use "While True" (and you might as well get rid of the
CloseSocket call, too). If the app will shut down in response to some signal
received over the socket, just set m_bDone to True whenever that signal
comes in.

--------------------------

You'd change OpenSocket/CloseSocket to LoadData/FreeData.


Quote:
> An ActiveX exe will stay resident if there is a loaded (but hidden) form.
> Make sure you provide the means to unload the form (via a method on a
public
> object).  Sounds like a pretty fun project, actually.  I'd be interested
to
> know how it works out.

> -Jon



> > cool idea! mmmm.... how brave am i? maybe not that brave ,,,,,,

> > What about this EXE idea? The problem I have with it, is persisting it.
> That
> > means a timer, or a loaded form, or something, doesn't it?

> > --
> > Kind Regards,

> > Robert A. Ellis, MCSD
> > Software Developer



> > > The ActiveX .exe loaded at boot sounds pretty straightforward to me,
but
> > if
> > > you want the ultimate in speed...

> > > This'll sound whacked at first, but it could be done. Since VB source
> > files
> > > are simple text files, you could create a server process that runs
every
> > > morning at 5, queries the database, and creates a VB source file that
> > > hardcodes the values into arrays. Then it could kick off VB with the
> /make
> > > argument to recompile the program each day and copy the .exe out to
the
> > > network where everyone runs it from. When the users run the app, it
> > doesn't
> > > have to load the values from disk and doesn't have to query the
> database;
> > > all the data is already compiled into the program in the arrays.



> > > > Yep, sure, that's how it is set up now and it works quite well. But
we
> > > wanna
> > > > go *faster*.

> > > > --
> > > > Kind Regards,

> > > > Robert A. Ellis, MCSD
> > > > Software Developer



> > > > > I would not leave them memory resident, I would persist them to
the
> > hard
> > > > > drive, and then your app can load them from their persisted state
> > using
> > > > the
> > > > > Recordset.Open statement.  For instance:

> > > > >     (to persist to xml file)
> > > > >     objRec.Save strFileName, adPersistXML

> > > > >     (to load from xml file)
> > > > >     objRec.Open strFileName, , adOpenStatic,

adLockBatchOptimistic,

- Show quoted text -

Quote:
> > > > > adCmdFile

> > > > > HTH-Jon



> > > > > > Hi there,

> > > > > > I'm pretty sure I already know the answer to this one, but I'm
not
> > > gonna
> > > > > > take the risk of posting it in case I make a fool of myself -
> let's
> > > see
> > > > > what
> > > > > > you folks come up with first.

> > > > > > Say I want to load some data from a SQL Server ahead of time, so
> > that
> > > > when
> > > > > > my VB App starts up, the data (in this case, consisting of a
> number
> > of
> > > > > > client-side, disconnected, read only ADO Recordsets) is already
> > > > > > memory-resident.

> > > > > > So.....when the client workstations boot in the morning, they go
> off
> > > to
> > > > > the
> > > > > > SQL Server and grab this data and it just sits in RAM, doing
> nothing
> > > > until
> > > > > > my App starts. Then my APP can grab the data without having to
do
> a
> > > trip
> > > > > to
> > > > > > the server.

> > > > > > How do I accomplish this? Do I use a VB ActiveX EXE, scheduled
to
> > run
> > > at
> > > > > > boot? Or do I build a service ?  What is the best design ?

> > > > > >  TIA!
> > > > > > --
> > > > > > Kind Regards,

> > > > > > Robert A. Ellis, MCSD
> > > > > > Software Developer



Wed, 28 Jul 2004 04:59:43 GMT  
 Memory Resident Data
Best solution I found to this exact problem was to write an NT service
that loads a COM object.  Make the COM object a singleton, and the
same object is passed to every VB EXE that requests it.  Cache your
data in a dictionary or an array or some such thing, and bingo - you
have your data cached, and you can refresh it by simply stopping and
restarting the service (or -even better- call a method to refresh the
data).

You may get threading issues though, if you have a lot of apps trying
to access that static data - may be best to accessonce on boot and
then have them copy the data to their own local store.

This is quite easy to do for anyone with a *little* VC++ experience..
LMK if you want more details.

James

On Fri, 8 Feb 2002 14:15:02 -0500, "Jon Mundsack"

Quote:

>Hmm... if you want to share data between processes -- 1) the ActiveX exe
>process to load and maintain the recordsets, and 2) the application process
>that will access the recordsets -- you'll need to develop some sort of
>singleton pattern which is kind of tricky in VB.  Here is a page that talks
>about this subject and offers a technique to "sort of" achieve this:

>http://users.skynet.be/wvdd2/General_techniques/Singletons/singletons...

>This page also contains links to a couple other pages discussing this topic.

>HTH-Jon



>> Yep, sure, that's how it is set up now and it works quite well. But we
>wanna
>> go *faster*.

>> --
>> Kind Regards,

>> Robert A. Ellis, MCSD
>> Software Developer



>> > I would not leave them memory resident, I would persist them to the hard
>> > drive, and then your app can load them from their persisted state using
>> the
>> > Recordset.Open statement.  For instance:

>> >     (to persist to xml file)
>> >     objRec.Save strFileName, adPersistXML

>> >     (to load from xml file)
>> >     objRec.Open strFileName, , adOpenStatic, adLockBatchOptimistic,
>> > adCmdFile

>> > HTH-Jon



>> > > Hi there,

>> > > I'm pretty sure I already know the answer to this one, but I'm not
>gonna
>> > > take the risk of posting it in case I make a fool of myself - let's
>see
>> > what
>> > > you folks come up with first.

>> > > Say I want to load some data from a SQL Server ahead of time, so that
>> when
>> > > my VB App starts up, the data (in this case, consisting of a number of
>> > > client-side, disconnected, read only ADO Recordsets) is already
>> > > memory-resident.

>> > > So.....when the client workstations boot in the morning, they go off
>to
>> > the
>> > > SQL Server and grab this data and it just sits in RAM, doing nothing
>> until
>> > > my App starts. Then my APP can grab the data without having to do a
>trip
>> > to
>> > > the server.

>> > > How do I accomplish this? Do I use a VB ActiveX EXE, scheduled to run
>at
>> > > boot? Or do I build a service ?  What is the best design ?

>> > >  TIA!
>> > > --
>> > > Kind Regards,

>> > > Robert A. Ellis, MCSD
>> > > Software Developer



Wed, 28 Jul 2004 05:11:08 GMT  
 Memory Resident Data
Nice.  I like being able to do this without a form.

How would we shut down this process, then?  Since we're not talking about
using sockets here.


Quote:
> Or (I'm pretty sure) if it's busy doing something. This was a response I
> wrote to someone doing network work, but I think it can apply here as
well:

> --------------------------

> Do something like this:

>     Private Declare Function WaitMessage Lib "User32" () As Long
>     Private m_bDone As Boolean

>     Public Sub Main()

>         m_bDone = False
>         Call OpenSocket()

>         While Not m_bDone
>             WaitMessage
>             DoEvents
>         Wend

>         Call CloseSocket()

>     End Sub

> If you're planning on the app staying up forever (until reboot), s{*filter*}the
> m_bDone flag and just use "While True" (and you might as well get rid of
the
> CloseSocket call, too). If the app will shut down in response to some
signal
> received over the socket, just set m_bDone to True whenever that signal
> comes in.

> --------------------------

> You'd change OpenSocket/CloseSocket to LoadData/FreeData.



> > An ActiveX exe will stay resident if there is a loaded (but hidden)
form.
> > Make sure you provide the means to unload the form (via a method on a
> public
> > object).  Sounds like a pretty fun project, actually.  I'd be interested
> to
> > know how it works out.

> > -Jon



> > > cool idea! mmmm.... how brave am i? maybe not that brave ,,,,,,

> > > What about this EXE idea? The problem I have with it, is persisting
it.
> > That
> > > means a timer, or a loaded form, or something, doesn't it?

> > > --
> > > Kind Regards,

> > > Robert A. Ellis, MCSD
> > > Software Developer



> > > > The ActiveX .exe loaded at boot sounds pretty straightforward to me,
> but
> > > if
> > > > you want the ultimate in speed...

> > > > This'll sound whacked at first, but it could be done. Since VB
source
> > > files
> > > > are simple text files, you could create a server process that runs
> every
> > > > morning at 5, queries the database, and creates a VB source file
that
> > > > hardcodes the values into arrays. Then it could kick off VB with the
> > /make
> > > > argument to recompile the program each day and copy the .exe out to
> the
> > > > network where everyone runs it from. When the users run the app, it
> > > doesn't
> > > > have to load the values from disk and doesn't have to query the
> > database;
> > > > all the data is already compiled into the program in the arrays.



> > > > > Yep, sure, that's how it is set up now and it works quite well.
But
> we
> > > > wanna
> > > > > go *faster*.

> > > > > --
> > > > > Kind Regards,

> > > > > Robert A. Ellis, MCSD
> > > > > Software Developer



> > > > > > I would not leave them memory resident, I would persist them to
> the
> > > hard
> > > > > > drive, and then your app can load them from their persisted
state
> > > using
> > > > > the
> > > > > > Recordset.Open statement.  For instance:

> > > > > >     (to persist to xml file)
> > > > > >     objRec.Save strFileName, adPersistXML

> > > > > >     (to load from xml file)
> > > > > >     objRec.Open strFileName, , adOpenStatic,
> adLockBatchOptimistic,
> > > > > > adCmdFile

> > > > > > HTH-Jon



> > > > > > > Hi there,

> > > > > > > I'm pretty sure I already know the answer to this one, but I'm
> not
> > > > gonna
> > > > > > > take the risk of posting it in case I make a fool of myself -
> > let's
> > > > see
> > > > > > what
> > > > > > > you folks come up with first.

> > > > > > > Say I want to load some data from a SQL Server ahead of time,
so
> > > that
> > > > > when
> > > > > > > my VB App starts up, the data (in this case, consisting of a
> > number
> > > of
> > > > > > > client-side, disconnected, read only ADO Recordsets) is
already
> > > > > > > memory-resident.

> > > > > > > So.....when the client workstations boot in the morning, they
go
> > off
> > > > to
> > > > > > the
> > > > > > > SQL Server and grab this data and it just sits in RAM, doing
> > nothing
> > > > > until
> > > > > > > my App starts. Then my APP can grab the data without having to
> do
> > a
> > > > trip
> > > > > > to
> > > > > > > the server.

> > > > > > > How do I accomplish this? Do I use a VB ActiveX EXE, scheduled
> to
> > > run
> > > > at
> > > > > > > boot? Or do I build a service ?  What is the best design ?

> > > > > > >  TIA!
> > > > > > > --
> > > > > > > Kind Regards,

> > > > > > > Robert A. Ellis, MCSD
> > > > > > > Software Developer



Wed, 28 Jul 2004 05:11:52 GMT  
 Memory Resident Data
Actually, maybe someone in the C++/Windows SDK world could help us (me) out
with that. Do you buy into the argument that essentially we are creating a
"service" (conceptually speaking) ? I do. So why can't we get access to the
same APIs  - those that tell a genuine service to startup & shutdown?
Developers who write services must know where those APIs are at ..... once
you have found them, presumably you can just poll for a value or
something.........

Any thoughts??

--
Kind Regards,

Robert A. Ellis, MCSD
Software Developer


Quote:
> Nice.  I like being able to do this without a form.

> How would we shut down this process, then?  Since we're not talking about
> using sockets here.



> > Or (I'm pretty sure) if it's busy doing something. This was a response I
> > wrote to someone doing network work, but I think it can apply here as
> well:

> > --------------------------

> > Do something like this:

> >     Private Declare Function WaitMessage Lib "User32" () As Long
> >     Private m_bDone As Boolean

> >     Public Sub Main()

> >         m_bDone = False
> >         Call OpenSocket()

> >         While Not m_bDone
> >             WaitMessage
> >             DoEvents
> >         Wend

> >         Call CloseSocket()

> >     End Sub

> > If you're planning on the app staying up forever (until reboot), s{*filter*}
the
> > m_bDone flag and just use "While True" (and you might as well get rid of
> the
> > CloseSocket call, too). If the app will shut down in response to some
> signal
> > received over the socket, just set m_bDone to True whenever that signal
> > comes in.

> > --------------------------

> > You'd change OpenSocket/CloseSocket to LoadData/FreeData.



> > > An ActiveX exe will stay resident if there is a loaded (but hidden)
> form.
> > > Make sure you provide the means to unload the form (via a method on a
> > public
> > > object).  Sounds like a pretty fun project, actually.  I'd be
interested
> > to
> > > know how it works out.

> > > -Jon



> > > > cool idea! mmmm.... how brave am i? maybe not that brave ,,,,,,

> > > > What about this EXE idea? The problem I have with it, is persisting
> it.
> > > That
> > > > means a timer, or a loaded form, or something, doesn't it?

> > > > --
> > > > Kind Regards,

> > > > Robert A. Ellis, MCSD
> > > > Software Developer



> > > > > The ActiveX .exe loaded at boot sounds pretty straightforward to
me,
> > but
> > > > if
> > > > > you want the ultimate in speed...

> > > > > This'll sound whacked at first, but it could be done. Since VB
> source
> > > > files
> > > > > are simple text files, you could create a server process that runs
> > every
> > > > > morning at 5, queries the database, and creates a VB source file
> that
> > > > > hardcodes the values into arrays. Then it could kick off VB with
the
> > > /make
> > > > > argument to recompile the program each day and copy the .exe out
to
> > the
> > > > > network where everyone runs it from. When the users run the app,
it
> > > > doesn't
> > > > > have to load the values from disk and doesn't have to query the
> > > database;
> > > > > all the data is already compiled into the program in the arrays.



> > > > > > Yep, sure, that's how it is set up now and it works quite well.
> But
> > we
> > > > > wanna
> > > > > > go *faster*.

> > > > > > --
> > > > > > Kind Regards,

> > > > > > Robert A. Ellis, MCSD
> > > > > > Software Developer



> > > > > > > I would not leave them memory resident, I would persist them
to
> > the
> > > > hard
> > > > > > > drive, and then your app can load them from their persisted
> state
> > > > using
> > > > > > the
> > > > > > > Recordset.Open statement.  For instance:

> > > > > > >     (to persist to xml file)
> > > > > > >     objRec.Save strFileName, adPersistXML

> > > > > > >     (to load from xml file)
> > > > > > >     objRec.Open strFileName, , adOpenStatic,
> > adLockBatchOptimistic,
> > > > > > > adCmdFile

> > > > > > > HTH-Jon



> > > > > > > > Hi there,

> > > > > > > > I'm pretty sure I already know the answer to this one, but
I'm
> > not
> > > > > gonna
> > > > > > > > take the risk of posting it in case I make a fool of
myself -
> > > let's
> > > > > see
> > > > > > > what
> > > > > > > > you folks come up with first.

> > > > > > > > Say I want to load some data from a SQL Server ahead of
time,
> so
> > > > that
> > > > > > when
> > > > > > > > my VB App starts up, the data (in this case, consisting of a
> > > number
> > > > of
> > > > > > > > client-side, disconnected, read only ADO Recordsets) is
> already
> > > > > > > > memory-resident.

> > > > > > > > So.....when the client workstations boot in the morning,
they
> go
> > > off
> > > > > to
> > > > > > > the
> > > > > > > > SQL Server and grab this data and it just sits in RAM, doing
> > > nothing
> > > > > > until
> > > > > > > > my App starts. Then my APP can grab the data without having
to
> > do
> > > a
> > > > > trip
> > > > > > > to
> > > > > > > > the server.

> > > > > > > > How do I accomplish this? Do I use a VB ActiveX EXE,
scheduled
> > to
> > > > run
> > > > > at
> > > > > > > > boot? Or do I build a service ?  What is the best design ?

> > > > > > > >  TIA!
> > > > > > > > --
> > > > > > > > Kind Regards,

> > > > > > > > Robert A. Ellis, MCSD
> > > > > > > > Software Developer



Wed, 28 Jul 2004 07:01:28 GMT  
 Memory Resident Data
Change m_bDone to g_bDone (make it a global) and then have one of methods in
the data-providing class be a QuitIt method which sets g_bDone to True.

Although if you shut it down, there went the advantage of having it cached
in the first place...

Oh, you meant when the user tries to shut Windows down? Just wait. Sooner or
later, Windows _always_ comes down...  :^)

But seriously, to bring it down automatically when Windows comes down, you'd
probably need to set up a message hook to watch for WM_QUERYENDSESSION, or
something along those lines.


Quote:
> Nice.  I like being able to do this without a form.

> How would we shut down this process, then?  Since we're not talking about
> using sockets here.



> > Or (I'm pretty sure) if it's busy doing something. This was a response I
> > wrote to someone doing network work, but I think it can apply here as
> well:

> > --------------------------

> > Do something like this:

> >     Private Declare Function WaitMessage Lib "User32" () As Long
> >     Private m_bDone As Boolean

> >     Public Sub Main()

> >         m_bDone = False
> >         Call OpenSocket()

> >         While Not m_bDone
> >             WaitMessage
> >             DoEvents
> >         Wend

> >         Call CloseSocket()

> >     End Sub

> > If you're planning on the app staying up forever (until reboot), s{*filter*}
the
> > m_bDone flag and just use "While True" (and you might as well get rid of
> the
> > CloseSocket call, too). If the app will shut down in response to some
> signal
> > received over the socket, just set m_bDone to True whenever that signal
> > comes in.

> > --------------------------

> > You'd change OpenSocket/CloseSocket to LoadData/FreeData.



> > > An ActiveX exe will stay resident if there is a loaded (but hidden)
> form.
> > > Make sure you provide the means to unload the form (via a method on a
> > public
> > > object).  Sounds like a pretty fun project, actually.  I'd be
interested
> > to
> > > know how it works out.

> > > -Jon



> > > > cool idea! mmmm.... how brave am i? maybe not that brave ,,,,,,

> > > > What about this EXE idea? The problem I have with it, is persisting
> it.
> > > That
> > > > means a timer, or a loaded form, or something, doesn't it?

> > > > --
> > > > Kind Regards,

> > > > Robert A. Ellis, MCSD
> > > > Software Developer



> > > > > The ActiveX .exe loaded at boot sounds pretty straightforward to
me,
> > but
> > > > if
> > > > > you want the ultimate in speed...

> > > > > This'll sound whacked at first, but it could be done. Since VB
> source
> > > > files
> > > > > are simple text files, you could create a server process that runs
> > every
> > > > > morning at 5, queries the database, and creates a VB source file
> that
> > > > > hardcodes the values into arrays. Then it could kick off VB with
the
> > > /make
> > > > > argument to recompile the program each day and copy the .exe out
to
> > the
> > > > > network where everyone runs it from. When the users run the app,
it
> > > > doesn't
> > > > > have to load the values from disk and doesn't have to query the
> > > database;
> > > > > all the data is already compiled into the program in the arrays.



> > > > > > Yep, sure, that's how it is set up now and it works quite well.
> But
> > we
> > > > > wanna
> > > > > > go *faster*.

> > > > > > --
> > > > > > Kind Regards,

> > > > > > Robert A. Ellis, MCSD
> > > > > > Software Developer



> > > > > > > I would not leave them memory resident, I would persist them
to
> > the
> > > > hard
> > > > > > > drive, and then your app can load them from their persisted
> state
> > > > using
> > > > > > the
> > > > > > > Recordset.Open statement.  For instance:

> > > > > > >     (to persist to xml file)
> > > > > > >     objRec.Save strFileName, adPersistXML

> > > > > > >     (to load from xml file)
> > > > > > >     objRec.Open strFileName, , adOpenStatic,
> > adLockBatchOptimistic,
> > > > > > > adCmdFile

> > > > > > > HTH-Jon



> > > > > > > > Hi there,

> > > > > > > > I'm pretty sure I already know the answer to this one, but
I'm
> > not
> > > > > gonna
> > > > > > > > take the risk of posting it in case I make a fool of
myself -
> > > let's
> > > > > see
> > > > > > > what
> > > > > > > > you folks come up with first.

> > > > > > > > Say I want to load some data from a SQL Server ahead of
time,
> so
> > > > that
> > > > > > when
> > > > > > > > my VB App starts up, the data (in this case, consisting of a
> > > number
> > > > of
> > > > > > > > client-side, disconnected, read only ADO Recordsets) is
> already
> > > > > > > > memory-resident.

> > > > > > > > So.....when the client workstations boot in the morning,
they
> go
> > > off
> > > > > to
> > > > > > > the
> > > > > > > > SQL Server and grab this data and it just sits in RAM, doing
> > > nothing
> > > > > > until
> > > > > > > > my App starts. Then my APP can grab the data without having
to
> > do
> > > a
> > > > > trip
> > > > > > > to
> > > > > > > > the server.

> > > > > > > > How do I accomplish this? Do I use a VB ActiveX EXE,
scheduled
> > to
> > > > run
> > > > > at
> > > > > > > > boot? Or do I build a service ?  What is the best design ?

> > > > > > > >  TIA!
> > > > > > > > --
> > > > > > > > Kind Regards,

> > > > > > > > Robert A. Ellis, MCSD
> > > > > > > > Software Developer



Wed, 28 Jul 2004 07:10:47 GMT  
 
 [ 13 post ] 

 Relevant Pages 

1. Memory Resident Data

2. Memory Resident Applications

3. Memory Resident

4. Calling memory-resident procedures

5. Memory Resident (2nd Post)

6. Memory Resident QB

7. memory resident database

8. How PROGRAMMATICALLY ShutDown a memory resident program ?

9. Making a VB Memory Resident Program?

10. memory resident program

11. How make prg on resident memory

12. Memory Resident Applications

 

 
Powered by phpBB® Forum Software