Author |
Message |
Robert Elli #1 / 13
|
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 |
|
|
Jon Mundsac #2 / 13
|
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 |
|
|
Robert Elli #3 / 13
|
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 |
|
|
Jon Mundsac #4 / 13
|
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 |
|
|
Dewayne Christense #5 / 13
|
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 |
|
|
Robert Elli #6 / 13
|
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 |
|
|
Jon Mundsac #7 / 13
|
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 |
|
|
Robert Elli #8 / 13
|
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, 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 |
|
|
Dewayne Christense #9 / 13
|
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, 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 |
|
|
James Ingra #10 / 13
|
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 |
|
|
Jon Mundsac #11 / 13
|
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 |
|
|
Robert Elli #12 / 13
|
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 |
|
|
Dewayne Christense #13 / 13
|
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 |
|
|
|