Hi, I'm changing the way I am distributing my software from a model where the application resided on the client's server, to a SAAS style where I will now host my software on our own servers.  I'm specifically wondering how memory tables will work in the new environment.

I use memory tables in my apps mainly for collating data for reporting purposes.  In the past there is usually only one or two people per client that would generate reports so I haven't needed to worry about how users interact with memory tables.  Now there will be multiple different clients running on the same server, with the software using the same DBISAM session and database name.  

Obviously the databases will reside in different folders, but what about the memory tables?  Would they be accessible by anyone on the server?  I’m not sure what any implications are.

Thanks
Col

Colin Wood wrote:

> Hi, I'm changing the way I am distributing my software from a model
> where the application resided on the client's server, to a SAAS style
> where I will now host my software on our own servers.  I'm
> specifically wondering how memory tables will work in the new
> environment.
>
> I use memory tables in my apps mainly for collating data for
> reporting purposes.  In the past there is usually only one or two
> people per client that would generate reports so I haven't needed to
> worry about how users interact with memory tables.  Now there will be
> multiple different clients running on the same server, with the
> software using the same DBISAM session and database name.
>
> Obviously the databases will reside in different folders, but what
> about the memory tables?  Would they be accessible by anyone on the
> server?  I’m not sure what any implications are.

I can't answer your main question, but I'll put my thoughts in anyway.
First, I'd make it all disk based, for pure persistence. It guarantees
you separate the data too.

But also, seriously look into converting to ElevateDB at this point. I
too was a DBISAM fan (and it still does good stuff), but one day as I
was making my web shop, I thought that the ideal time was to convert
before I have any real data, rather than when it is live and becomes
awkward. I posted my findings, but in summary converting your existing
code is a matter of renaming components and doesn't take at all long.
And you end up with a far more modern and flexible system. I've not
regretted the switch for a moment (I took backups of course in case it
went wrong, but it was never an issue at all).

Once that is done, you can ask how memory databases work in EDB
instead. 8-)

--

Matthew Jones

Colin


I never used c/s in DBISAM at all but from my memory of these news groups the memory tables are separated by process - effectively by user or login.

Roy Lambert

Thanks for your comments Matthew and Roy.
I have actually gone down the road of converting everything from DBISAM to EDB but I found it involved a lot more than simply renaming components and it did take me quite some time. However, I have switched back to DBISAM, which probably says a lot more about my basic programming skills than Tim’s fantastic program.  

I’m utilising TSPLUS to provide a seamless remote application to my clients.  TSPLUS also enables me to provide HTML5 access to my apps with very little mods to the existing VCL development.  I’m still running DBISAM as a local database.  I’ve found it to be a rock solid platform that just works for me.  I may well delve back into EDB later, but my intention is to outsource that work, as I try to extricate myself from the coding side of the business.

I’m relieved to hear your comment about the memory tables Ray.  That should mean I don’t have to worry about anything much at the moment.

Cheers
Colin

Colin


>I have actually gone down the road of converting everything from DBISAM to EDB but I found it involved a lot more than simply renaming components and it did take me quite some time. However, I have switched back to DBISAM, which probably says a lot more about my basic programming skills than Tim’s fantastic program.

My main driver for the switch was the improvements in full text indexing and the pain of conversion was worth it for that alone. I think its more about the mindset than programming skills, that and the fact that Tim did such a great job with DBISAM. The first and biggest mind shift is moving from dealing with individual tables and having to deal with the configuration & catalog. Not difficult but different - it seems to throw everyone to start with. There are a few nasties and I still miss things like IF EXISTS for changing tables in SQL. Nothing to major.

>I’m utilising TSPLUS to provide a seamless remote application to my clients. TSPLUS also enables me to provide HTML5 access to my apps with very little mods to the existing VCL development. I’m still running DBISAM as a local database. I’ve found it to be a rock solid platform that just works for me. I may well delve back into EDB later, but my intention is to outsource that work, as I try to extricate myself from the coding side of the business.

As Sir Humphrey would say - "a brave decision"

>I’m relieved to hear your comment about the memory tables Ray. That should mean I don’t have to worry about anything much at the moment.

Who's Ray

Roy

Roy

I'm sure I said "Roy". You might have heard "Ray" but I'm putting that down to my strange Aussie accent

>As Sir Humphrey would say - "a brave decision"

Hmm.  I recall that a "brave" decision was just a bit better than a "courageous" one.  So Roy, what pitfalls do you see with going down the TSPlus route?

On 2/13/2016 11:09 PM, Colin Wood wrote:
> I have actually gone down the road of converting everything from DBISAM to EDB but I found it involved a lot more than simply renaming components and it did take me quite some time.

If one simply uses the basic dataset type functionality (i.e. data bound
controls and table/query components) the switch is relatively
straightforward (you still need to get your head around EDB architecture
including catalogue etc).

However if you're like us and use lot of DBISAM SQL then the switch can
be lot more involved. In our case we evaluated switch to EDB and for now
at least in our main app are sticking with DBISAM as well.

Not to mention of course that DBISAM has been rock solid and working
really well so "if it ain't broke ..." very much applies as well.

Raul

On 2/13/2016 5:21 AM, Colin Wood wrote:
> Hi, I'm changing the way I am distributing my software from a model where the application resided on the client's server, to a SAAS style where I will now host my software on our own servers.  I'm specifically wondering how memory tables will work in the new environment.

For one they will be server based (i.e. dbsrvr) for remote sessions and
like Roy indicated separated by process - so your app can access same
memory tables using different session but only from that app instance.

> Obviously the databases will reside in different folders, but what about the memory tables?  Would they be accessible by anyone on the server?  I’m not sure what any implications are.

Have not looked into this in a while but as i recall the actual memory
tables did appear to be in memory (of dbsrvr).

Any non-live query will result in a temp table being generated in temp
folder location (for dbsrvr) but also deleted once you close the results.

So you multi-user sceanrio should be fine,

If you do allow them to save the result of reporting queries as normal
on-disk tables then those of course will be accessible by anybody who
has remote database (access) for that folder.

Raul

Colin

>I'm sure I said "Roy". You might have heard "Ray" but I'm putting that down to my strange Aussie accent
>
>>As Sir Humphrey would say - "a brave decision"
>
>Hmm. I recall that a "brave" decision was just a bit better than a "courageous" one. So Roy, what pitfalls do you see with going down the TSPlus route?

Just the experience of many large organisations outsourcing

Roy

Raul wrote:

> Not to mention of course that DBISAM has been rock solid and working
> really well so "if it ain't broke ..." very much applies as well.

Yes, I agree, but this is a big change, so why not benefit from it?

Obviously the specific circumnstances matter too. Both are good solid
products.

FWIW, one thing that made the change easy for me was writing my own SQL
Builder component. It has annoyed me since forever that the SQL for
UPDATE is so different from the SQL for INSERT, but too many times I
have to do an update, and if nothing updated, then insert. Or
variations on that sort of theme. So I wrote a component to build SQL
for me, and I just do things like:

 xQueryBuilder := TSqlBuilder.Create;
 xQueryBuilder.WhereClause := 'WHERE (caCustomerRef = :CUSTREF)';
 xQueryBuilder.TableName := 'CustomerAccount';
 xQueryBuilder.AddValue('caAccountIsAcademic', '');
 xQueryBuilder.AddValue('caAccountEmail', '');

 xWorkQuery.SQL.Text := xQueryBuilder.SelectQuery;

Having done that, switching to EDB was simple, as the changes were
encapsulated in one place. The component is nothing fancy - plenty of
schemes people made that do very clever things but they aren't my
style. But this has made my SQL so much clearer and simpler. (Not
trying to convert anyone here, just saying that if you've had a desire
to do something like this, make it happen as I wish I'd done it years
ago!)

--

Matthew Jones