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

--

"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

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]

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


--

"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

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




--

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




--

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]

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
>
>
>
>

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




--