Any update Marco - customer was on about this earlier in the week as a single instance of the app was using over 80Mb and the terminal server was less than entirely happy.
Any update on the Marco? Not heard anything since sending the sample app (over 2 months ago).
Don't want to redo a couple of million lines of code to use a different dataset if I can avoid it.
I've upgraded to 4.1 and this is still happening, strange though it may be, it is definitely dependent on other apps. This is why it has taken me so long to trace the cause. I do not know if this is down to them using memory or processor, but would imagine memory.
I'm seeing it increasing by...
Was this ever resolved? If so in which version?
I'm having the same issue in 4.0.7 If you sit and watch Task Manager while it refreshes (the TOracleDataset) the memory use seems to remain fairly constant, but if you try to do other things (open Word, etc.) while the refresh process is running...
Have a bit of a strange problem, wouldn't be an issue but some users 'need' to work on thousands of records in one grid.
Have an OracleDataset, linked to a ClientDataset via a DatasetProvider. Which works fine. The problem arises when I try to refresh one record on the clientdataset...
Ideally server, but client would do (if the user has a 10 client then the server will be 10). Prior to 10 we had a service that ran for updating Oracle Text indexes. On login to the program a warning would flash up if the service was not running. In 10 this service is not required so I don't...
Is there any way of knowing if the user has 10g installed?
By using OracleCI we can check up to 9, but we need to find out if the user has 10 installed.
Thanks
Thanks (sorry, not had much time to look at this recently) but the trigger is just running a straight forward insert (via stored procedures/functions)which if my understanding is correct is already an implicit cursor.
It can be demonstrated by creating an after-insert trigger for emp:
CREATE OR...
Tried it against the emp table and got different behaviour. Not had a chance yet to work out why, may have something to do with us having triggers on insert/update/delete to do custom auditing. Would there be any reason why an 'insert into audit-table' sql command ran inside a trigger would...
This is running DOA 3.4.6.1 in Delphi 6 against Oracle 8.17. Same problem exists against Oracle 9.
When using DOA 4.0.5 it adds to the number of open cursors each time, rather than reusing them across queries (as it does in 3):
q1 uses 4 cursors
q2 uses 1 cursor
q3 uses 1 cursor
In 3...