What are files _QSQ99.DB & DEL107.MB? 5

[delphiman]

These files are being created in the folder where my source files are.

Upon running my project (from within the environment and
whilst it is still loading the files) it has suddenly taken to giving me an exception which refers to _QSQ99.DB or (some similar file) to the effect that I have "not enough memory".

Which has to be false because I have in excess of 600Mb of RAM.

If I simply pump F9 as and when I get the exception the files continue to load until and eventually the program runs successfully - but more and more of these files are created.

If I simply delete them all that happens is I get less exceptions next time round.

If I run the program from OUTSIDE the environment (i.e. the .exe file) it works fine.

Anyone?

 

[delphiman]

I should have added the exact exception which I get which is as follows ...

Project MyProg.exe raised exception class EDBEngineError with message 'Capability not 
supported. Insufficient memory for this operation.
Table: C:\Program Files\LAB\MyProg\_QSQ131.DB."

 

[ChrisGSchultz]

It looks like your performing an SQL query - is that the case? Please provide more details (ie the context of the error).

The DB file is a Paradox database, used temporarily to perform a query. Deleting the DB files will release file locks.

If your query is very large or has errors in it, it would return errors such as this. Try searching the help file for the specific exception error for more information.

If your query is at fault, you can test it out using the database desktop

Any other suggestions out there?

Chris ;-)

 

[svanels]

The culprit could be some auto create form with a database component acessing the database at start-up, or maybe a datamodule preparing a query at run-time.

Steven van Els
SAvanEls@cq-link.sr

 

[delphiman]

ChrisGSchultz (IS/IT--Manageme) 9 Mar 05 22:24
It looks like your performing an SQL query

Yup! Several ... but these have not caused complications in the past.It seems the problem is being created by the recent additional forms which I have included.

I suspect I shall have to seriously consider creating some (if not all) of these forms dynamically. Alternatively I might have to break up the project into packages.

Steve van Else.
You are also right ... but see above.

 

[Nordlund]

The errormessage "Insufficient memory for this operation.
" is a BDE bug.

Restart all BDE related applications and the error is gone... For the moment...

This is because you terminate the application in Delphi environment, and start it again... * 10 times (or more)

The BDE doesn't free up it's memory...

This text was found at the Delphi community website:

More than likely, you have hit one of the BDE fixed, but configurable, memory limitations. Use the BDE Administrator (BDEADMIN.EXE) to increase MEMSIZE and SHAREDMEMSIZE settings. You might also want to re-evaluate the application hitting this limitation because it is likely that the application is a serious resource hit on the machine. Not using auto-create forms and only opening tables and queries when needed can free up resources.

//Nordlund

 

[delphiman]

Thanks to my son (in Cape Town: South Africa who was programming in machine code at the age of 12 on my Sharp 3201) I (now in Melbourne Australia) now have the total solution to this problem. Which I think is worth adding here and is as as I got it from him

The first thing to do is backup all your source, because you are going to be messing around a lot with the innards of your program.

Next, Open your project in Delpi and open the Delphi Project menu and choose Options. A form will come up, make sure you are looking at the Forms tab.

There are 2 columns. I suspect all your forms are sitting in the left column. Herein lies the problem. Delphi is "auto-creating" all those forms for you. Move them all over to the right hand column.

THEN, select the form which is the first form the user must see when he runs your program in the RIGHT hand column and MOVE IT BACK to the LEFT hand column.

Then click OK.

What you have done now is tell Delphi to desist from AutoCreating the forms for you. Because you are going to do it yourself dynamically during execution of your program.

Next : Go to all the places in your program where you call the .ShowModal or .Show methods and replace them.

This sort of thing : frmDbtrs.ShowModal
must change to

  frmDbtrs := TFrmDbtrs.Create(nil);
  frmDbtrs.ShowModal;

Remembering that QuickReport forms are treated the same way - as follows (Note the "T")

   QuickReportCB := TQuickReportCB.Create(nil);
   QuickReportCB.Print;

When you've changed all of those, you need to go to each of the forms which you create this way and go and add this in the OnClose event of
those forms :

  Action := caFree;

This is where the real fun stuff starts. The reason you are going to pick them up at this stage is that previously ALL the forms were being created in memory by Delphi
before the program even started running, so it was possible for you to reference an object on a different form quite easily, simply by making sure the "other form"'s name was in the Uses clause.

The problem now is, you can no longer rely on that "other form" even existing yet in memory, and the moment your program tries to access something which doesn't yet exist in memory, you will hit an exception or access violation error.

This is not actually a bad thing. What you would have done up until this point (by changing everything the way I showed you earlier) is "compartmentalise" and isolate everything (each form) nicely into it's own box - which is what a good object oriented program is all about. Each
object (or unit/form) should ideally not have any dependencies on OTHER forms or units. This has NOTHING to do with how your program works - it's simply more technically correct OBJECT ORIENTED thing programmatically -whether it's Delphi, C++ or Java - the same applies.

However, sometimes, you simply HAVE to do this to share info or whatever between forms. This is why Borland came up with the idea of the DATA MODULE (don't know if you use them yet, but now you must I think, if you aren't already).

The idea is to move all your "common" things (things / data/ objects / queries / tables / whatever) which you want to SHARE amongst different units / forms into a DATA MODULE.

THAT data module must then sit in the left hand column of the Project/Options/Forms screen AT THE TOP and BEFORE your startup form.

To get this right is inevitably going to involve a bit of a code "walk through" and you might have to rethink some of your logic - it will help to draw diagrams on paper of how the different units/forms need to interact with each other before starting, so you can more quickly identify just WHAT needs to move into the data module.

 

[svanels]

Terry, you are using Interbase, so I first didn't get the paradox file, but seeing quick-reports being generated it makes sense.

Steven van Els
SAvanEls@cq-link.sr

 

[delphiman]

Nice hearing from you again Steven!

I am not using Interbase as the application is designed to be used on a stand-alone (Paradox) basis by single users. Where (if necessary) a LAN would easily suffice for expansion to other (local) systems.

This is essentially because (as you will know) Borland require a "seat licence" on every system that uses Interbase. Which in itself need not be a problem - provided that one is dealing with large institutions (who can afford it) AND Borland deems it suitable to
respond to (endless) enquiries as to how much the licence is and to whom to pay it.

After endless enquiries to Borland about this I simply gave up when all these queries went un-answered.

I would have preferred the application (which I shall be marketing world-wide) to be Interbase SQL-based as "standard" - thus leaving my user with the (very attractive) option of being able to expand its application (world-wide to other branches of his/her business!) from a common server at any time. Which competitive products don't provide AND thus getting up the nose of old "Billy".

But I can't imagine a (temporary?) single-user being prepared to pay an on-going fee (indefinately) for this licence on just ONE site. On the basis that "one day" (maybe!) they could make full use of the fact that it is Interbase SQL based.

TERRY

 

[svanels]

Well firebird is the opensource version of Interbase, I assume that technically speaking there are not much differences. In theory it must be possible to transfer the metadata from interbase to firebird, and there would be no need to modify your application code, right?

Steven van Els
SAvanEls@cq-link.sr