Subject | Memory use and TIB_DSQL |
---|---|
Author | Michael Vilhelmsen |
Post date | 2004-03-08T07:45:51Z |
Hi
Last week I had a longer posting with Helen (thank you for that
Helen).
I experienced that using TIB_DSQL with my appl. made it use lot af
ram.
My work has been like this:
1.
I ordered IBObjects and switched from a BDE appl. to a IBO using
GReplace.
So fine so good.
This appl. has been running for 2 months.
2.
I changed every TIBOQuery I had in my appl. that does a SELECT ....
and that doesn't need to to be displayed on any form.
This worked fine as well.
3.
I changed every TIBOQuery that does a INSERT INTO...., DELETE
FROM..... and UPDATE TABLE SET..... to TIB_DSQL.
When doing this last thing, but appl. didn't free up RAM again.
We have some clients coonecting to a Windows Terminal Server or to a
Citrix server.
Our Citrix server has 2 Gb of RAM and I found out last week that
almost all RAM was in use dispite the fact that only 7 clients where
attached. Each client used some 150 - 300 Mb of RAM with this appl.
4.
I then switched those TIB_DSQL back to TIBOQuery and the problem
disapeared.
Now my appl. is a kind of POS system.
The user can type in a number, and from this I locate the right
record using a SELECT. If the record exists I either do a INSERT INTO
a temp. table that holds the records they have selected. Or I do a
UPDATE should the selected record already exists in this table.
After each Insert or Update I do a COMMIT.
When the customer has selected all records he wants I display a new
window where he can choose how this is going to be paid.
He can choose as many was a has been created in the system (normally
somewhere between 5 and 20).
After each of those are inserted into the same temp table. I do a
COMMITRETAINING (which I have tried to change to a COMMIT, but with
no luck).
Then a last the customer gets to choose wether or not to complete
this, meaning:
COMPLETE:
Update several tables in the DB using both Stored Procedures and
TIB_DSQL with Insert Into or Update.
Delete all records from the temp. table.
When all lines has been run through I do a COMMIT.
ABORT:
Insert a record in a table for each line, deleting the temp. table
and COMMIT.
Somewhere along the above RAM is being used, but never been given
free again.
I have tried running the appl. on my own 2 machines (one labtop, one
stationary PC). Here its the same, so its not our Terminal Server or
Citrix Server.
I have looked every where in my appl. for dbTables in the uses claus.
Its nowhere.
In this weekend I was home trying a lot of things to see if I could
get it to behave normally. No luck.
I use D5 Ent, QuickReport 3.6.2 pro, IBO 4.3Aa.
The DB is Firebird 1.0.3, but it has been tried up against FB 1.5.
But I can't see that it should be FB, since FB behaves normally. It
my appl. thats odd.
One thing I have noticed is, that sometimes when I do a COMMIT some
of my TIBOQuerys and TIB_Cursors are not closed yet. But then again
its not those comp. making the error. Its TIB_DSQL.
Any one with any good ideas ?
Michael
Last week I had a longer posting with Helen (thank you for that
Helen).
I experienced that using TIB_DSQL with my appl. made it use lot af
ram.
My work has been like this:
1.
I ordered IBObjects and switched from a BDE appl. to a IBO using
GReplace.
So fine so good.
This appl. has been running for 2 months.
2.
I changed every TIBOQuery I had in my appl. that does a SELECT ....
and that doesn't need to to be displayed on any form.
This worked fine as well.
3.
I changed every TIBOQuery that does a INSERT INTO...., DELETE
FROM..... and UPDATE TABLE SET..... to TIB_DSQL.
When doing this last thing, but appl. didn't free up RAM again.
We have some clients coonecting to a Windows Terminal Server or to a
Citrix server.
Our Citrix server has 2 Gb of RAM and I found out last week that
almost all RAM was in use dispite the fact that only 7 clients where
attached. Each client used some 150 - 300 Mb of RAM with this appl.
4.
I then switched those TIB_DSQL back to TIBOQuery and the problem
disapeared.
Now my appl. is a kind of POS system.
The user can type in a number, and from this I locate the right
record using a SELECT. If the record exists I either do a INSERT INTO
a temp. table that holds the records they have selected. Or I do a
UPDATE should the selected record already exists in this table.
After each Insert or Update I do a COMMIT.
When the customer has selected all records he wants I display a new
window where he can choose how this is going to be paid.
He can choose as many was a has been created in the system (normally
somewhere between 5 and 20).
After each of those are inserted into the same temp table. I do a
COMMITRETAINING (which I have tried to change to a COMMIT, but with
no luck).
Then a last the customer gets to choose wether or not to complete
this, meaning:
COMPLETE:
Update several tables in the DB using both Stored Procedures and
TIB_DSQL with Insert Into or Update.
Delete all records from the temp. table.
When all lines has been run through I do a COMMIT.
ABORT:
Insert a record in a table for each line, deleting the temp. table
and COMMIT.
Somewhere along the above RAM is being used, but never been given
free again.
I have tried running the appl. on my own 2 machines (one labtop, one
stationary PC). Here its the same, so its not our Terminal Server or
Citrix Server.
I have looked every where in my appl. for dbTables in the uses claus.
Its nowhere.
In this weekend I was home trying a lot of things to see if I could
get it to behave normally. No luck.
I use D5 Ent, QuickReport 3.6.2 pro, IBO 4.3Aa.
The DB is Firebird 1.0.3, but it has been tried up against FB 1.5.
But I can't see that it should be FB, since FB behaves normally. It
my appl. thats odd.
One thing I have noticed is, that sometimes when I do a COMMIT some
of my TIBOQuerys and TIB_Cursors are not closed yet. But then again
its not those comp. making the error. Its TIB_DSQL.
Any one with any good ideas ?
Michael