Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 10 of 14 total |
Memory Table Question |
Fri, Oct 16 2009 6:26 PM | Permanent Link |
"Mike Saunders" | Hi
I just want to check whether I should be able to access a memory table created by App A from another App B (same machine) (DBISAM 3.30) If yes then I will post my code for someone to check what my issue is Many thanks Mike -- |
Fri, Oct 16 2009 7:06 PM | Permanent Link |
"Robert" | "Mike Saunders" <enquiries@folleytech.co.uk> wrote in message news:458C25AC-DF17-4CDE-B78F-792B3F9A9971@news.elevatesoft.com... > Hi > > I just want to check whether I should be able to access a memory table > created by App A from another App B (same machine) (DBISAM 3.30) If yes > then I will post my code for someone to check what my issue is > You can, but it is not very simple. The way I approached it was to make a savetostream, a WM_COPYDATA, and then a load from stream. Looking back, saving to disk in the temp folder might have been just as good. Robert |
Sat, Oct 17 2009 1:33 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Mike
From my interpretation of your question I'd disagree with Robert. Memory tables are isolated within a Windows process. This means that multiple threads within an app can share access but a separate app can't. Robert's solution is the only one come up with some sort of interprocess transfer mechanism. Roy Lambert [Team Elevate] |
Sat, Oct 17 2009 6:03 AM | Permanent Link |
"Mike Saunders" | Roy Lambert wrote:
> Mike > > > From my interpretation of your question I'd disagree with Robert. > Memory tables are isolated within a Windows process. This means that > multiple threads within an app can share access but a separate app > can't. > > Robert's solution is the only one come up with some sort of > interprocess transfer mechanism. > > Roy Lambert [Team Elevate] That is a pity It would have been ideal for a fast and easy communication between Apps. The manual could have been somewhat clearer "Sharing In-Memory Tables In-memory tables can be shared just like regular disk-based tables. They are also thread-safe and exhibit the same locking and access behaviors." Mike -- |
Sat, Oct 17 2009 10:35 AM | Permanent Link |
"Robert" | "Mike Saunders" <enquiries@folleytech.co.uk> wrote in message news:885222F9-5ED5-4CF4-9AF6-1AE58A5FF560@news.elevatesoft.com... > Roy Lambert wrote: > >> Mike >> >> >> From my interpretation of your question I'd disagree with Robert. >> Memory tables are isolated within a Windows process. This means that >> multiple threads within an app can share access but a separate app >> can't. >> >> Robert's solution is the only one come up with some sort of >> interprocess transfer mechanism. >> >> Roy Lambert [Team Elevate] > > > That is a pity It would have been ideal for a fast and easy > communication between Apps. The manual could have been somewhat clearer > Well, I don't see how it can be a lot easier than doing a savetostream in the first app and passing the data to the other application that then does a loadfromstream. A few lines of code in each app. This method implies that the data is passed as static data - once the second app does the loadfromstream, it becomes its table, and any changes subsequently made by the first app will not be seen. If you need for both programs to modify the table concurrently, you will need to use a disk table (and take care of concurrency the normal way). > > "Sharing In-Memory Tables > > In-memory tables can be shared just like regular disk-based tables. > They are also thread-safe and exhibit the > same locking and access behaviors." > Since the manual (and common sense) tells you that a memory table goes away once the application goes away, I can't see how you could assume that somehow memory tables would reside in some mystery area of memory, independent of the application. Imagine app 2 happily reading the shared memory table created by app 1, and app 1 ends. The one shared area that persists after the application is gone is disk. Robert |
Sat, Oct 17 2009 11:35 AM | Permanent Link |
"Mike Saunders" | Robert wrote:
> > "Mike Saunders" <enquiries@folleytech.co.uk> wrote in message > news:885222F9-5ED5-4CF4-9AF6-1AE58A5FF560@news.elevatesoft.com... > > Roy Lambert wrote: > > > > > Mike > > > > > > > > > From my interpretation of your question I'd disagree with Robert. > > > Memory tables are isolated within a Windows process. This means > > > that multiple threads within an app can share access but a > > > separate app can't. > > > > > > Robert's solution is the only one come up with some sort of > > > interprocess transfer mechanism. > > > > > > Roy Lambert [Team Elevate] > > > > > > That is a pity It would have been ideal for a fast and easy > > communication between Apps. The manual could have been somewhat > > clearer > > > Well, I don't see how it can be a lot easier than doing a > savetostream in the first app and passing the data to the other > application that then does a loadfromstream. Well you did say that it wasn't simple but let me explain further The thing is one of my Apps is a DLL which will be called by non Deplhi Apps I have now got it to dynamically create my DBISAM objects and can access a disk file created by my Delphi App OK Not too sure about DLL's yet but as I figure as they are created dynamically when required I dont think I can use messages (ie they are not pesistent) Someone correct me if I am wrong > > This method implies that the data is passed as static data - once the > second app does the loadfromstream, it becomes its table, and any > changes subsequently made by the first app will not be seen. If you > need for both programs to modify the table concurrently, you will > need to use a disk table (and take care of concurrency the normal > way). I dont need concurrent access just a fast way to pass data so this would be fine if it suits my situation (see above) > > > > > "Sharing In-Memory Tables > > > > In-memory tables can be shared just like regular disk-based tables. > > They are also thread-safe and exhibit the > > same locking and access behaviors." > > > I can't see how you could> assume that somehow memory tables would reside in some mystery area> of memory, independent of the application. I hadn't. In had planned on the Delphi App creating and periodically updating the memory table whilst at all times being resident I wanted the Non Delphi Apps that use DLL's for table access to be able to access for updates as fast as possible They would also use a similar approach to pass data back to the main App Thanks Mike -- |
Sat, Oct 17 2009 11:36 AM | Permanent Link |
"Mike Saunders" | Robert wrote:
> > "Mike Saunders" <enquiries@folleytech.co.uk> wrote in message > news:885222F9-5ED5-4CF4-9AF6-1AE58A5FF560@news.elevatesoft.com... > > Roy Lambert wrote: > > > > > Mike > > > > > > > > > From my interpretation of your question I'd disagree with Robert. > > > Memory tables are isolated within a Windows process. This means > > > that multiple threads within an app can share access but a > > > separate app can't. > > > > > > Robert's solution is the only one come up with some sort of > > > interprocess transfer mechanism. > > > > > > Roy Lambert [Team Elevate] > > > > > > That is a pity It would have been ideal for a fast and easy > > communication between Apps. The manual could have been somewhat > > clearer > > > Well, I don't see how it can be a lot easier than doing a > savetostream in the first app and passing the data to the other > application that then does a loadfromstream. Well you did say that it wasn't simple but let me explain further The thing is one of my Apps is a DLL which will be called by non Deplhi Apps I have now got it to dynamically create my DBISAM objects and can access a disk file created by my Delphi App OK Not too sure about DLL's yet but as I figure as they are created dynamically when required I dont think I can use messages (ie they are not pesistent) Someone correct me if I am wrong > > This method implies that the data is passed as static data - once the > second app does the loadfromstream, it becomes its table, and any > changes subsequently made by the first app will not be seen. If you > need for both programs to modify the table concurrently, you will > need to use a disk table (and take care of concurrency the normal > way). I dont need concurrent access just a fast way to pass data so this would be fine if it suits my situation (see above) > > > > > "Sharing In-Memory Tables > > > > In-memory tables can be shared just like regular disk-based tables. > > They are also thread-safe and exhibit the > > same locking and access behaviors." > > > I can't see how you could> assume that somehow memory tables would reside in some mystery area> of memory, independent of the application. I hadn't. In had planned on the Delphi App creating and periodically updating the memory table whilst at all times being resident I wanted the Non Delphi Apps that use DLL's for table access to be able to access for updates as fast as possible They would also use a similar approach to pass data back to the main App Thanks Mike -- |
Sun, Oct 18 2009 3:35 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Mike
As Robert suggested just use a real DBISAM table. There's no advantage to using a memory table in the scenario you describe even if it would work. Its easy enough to do in a DLL, just like in an exe Roy Lambert [Team Elevate] |
Sun, Oct 18 2009 4:28 PM | Permanent Link |
Norman Rorke | Mike,
Can I suggest you look at this http://www.eldos.com/msgconnect/desc.php It is a cross-platform inter-application communication utility we have been using for years. Works across the network and has a tiny footprint. We also use it to communicate with a COM dll that is being accessed by non-Delphi apps. Norman Rorke Desktop Financials Ltd. Mike Saunders wrote: > Robert wrote: > >> "Mike Saunders" <enquiries@folleytech.co.uk> wrote in message >> news:885222F9-5ED5-4CF4-9AF6-1AE58A5FF560@news.elevatesoft.com... >>> Roy Lambert wrote: >>> >>>> Mike >>>> >>>> >>>> From my interpretation of your question I'd disagree with Robert. >>>> Memory tables are isolated within a Windows process. This means >>>> that multiple threads within an app can share access but a >>>> separate app can't. >>>> >>>> Robert's solution is the only one come up with some sort of >>>> interprocess transfer mechanism. >>>> >>>> Roy Lambert [Team Elevate] >>> >>> That is a pity It would have been ideal for a fast and easy >>> communication between Apps. The manual could have been somewhat >>> clearer >>> > > >> Well, I don't see how it can be a lot easier than doing a >> savetostream in the first app and passing the data to the other >> application that then does a loadfromstream. > > > Well you did say that it wasn't simple but let me explain further The > thing is one of my Apps is a DLL which will be called by non Deplhi > Apps I have now got it to dynamically create my DBISAM objects and can > access a disk file created by my Delphi App OK Not too sure about > DLL's yet but as I figure as they are created dynamically when required > I dont think I can use messages (ie they are not pesistent) Someone > correct me if I am wrong > > >> This method implies that the data is passed as static data - once the >> second app does the loadfromstream, it becomes its table, and any >> changes subsequently made by the first app will not be seen. If you >> need for both programs to modify the table concurrently, you will >> need to use a disk table (and take care of concurrency the normal >> way). > > > I dont need concurrent access just a fast way to pass data so this > would be fine if it suits my situation (see above) > >>> "Sharing In-Memory Tables >>> >>> In-memory tables can be shared just like regular disk-based tables. >>> They are also thread-safe and exhibit the >>> same locking and access behaviors." >>> > I can't see how you could> assume that somehow memory tables would > reside in some mystery area> of memory, independent of the application. > > > I hadn't. In had planned on the Delphi App creating and periodically > updating the memory table whilst at all times being resident I wanted > the Non Delphi Apps that use DLL's for table access to be able to > access for updates as fast as possible They would also use a similar > approach to pass data back to the main App > > Thanks > > Mike > > > > |
Wed, Oct 21 2009 11:54 AM | Permanent Link |
"Mike Saunders" | Norman Rorke wrote:
> Can I suggest you look at this > http://www.eldos.com/msgconnect/desc.php > > It is a cross-platform inter-application communication utility we > have been using for years. Works across the network and has a tiny > footprint. We also use it to communicate with a COM dll that is being > accessed by non-Delphi apps. > > Norman Rorke > Desktop Financials Ltd. Thanks that is a useful link to have I still am a little confused though Could you please explain how a non Delphi app can be instructed to perform an action by an App written in Delphi. At present my non delphi app simply calls the DLL when needed (or could be at fixed time intervals) and passes some data across ie its the non delphi app that initiates the action needed Wouldnt the DLL need to be always running (like an .exe) so that it could receive messages I have assumed that my present DLL could not receive messages when not being accessed from my non Delphi App Thanks Mike -- |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Sunday, May 19, 2024 at 08:46 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |