Hi Guys,
This may be normal operation.  Over the weekend I enabled I/O Buffering for my Client.
I have a utility that tells me all Apps & Tables that are open in the Clients App & Data directories.
This morning it is telling me that a particular set of tables that only ever get opened when doing an archive, are open.
Nobody is doing or has done an Archive.
Does I/O buffering open ALL tables in the database automatically?

Regards,
Ian

On 4/7/2019 6:44 PM, Ian Branch wrote:
> This may be normal operation.  Over the weekend I enabled I/O Buffering for my Client.
> I have a utility that tells me all Apps & Tables that are open in the Clients App & Data directories.
> This morning it is telling me that a particular set of tables that only ever get opened when doing an archive, are open.
> Nobody is doing or has done an Archive.
> Does I/O buffering open ALL tables in the database automatically?

Global I/O buffering does do exclusive open (and keeps files open) on
all the files it should buffer so it's definitely possible (config,
catalogue and table files).

What are your actual buffering setting - file specifications more
specifically ?

Raul

Raul wrote:

>>Global I/O buffering does do exclusive open (and keeps files open) on
all the files it should buffer so it's definitely possible (config,
catalogue and table files).

>>What are your actual buffering setting - file specifications more
specifically ?

Hi Raul,
I have specified several of the tables but none of the Archive tables that are now open.
I only specified the main files that are used on a day-to-day basis.
e.g.  *\Jobtickets.*.  No *\_AJobTickets.*.

It's not an issue, just unexpected.
Regards,
Ian

Ian,

<< Does I/O buffering open ALL tables in the database automatically? >>

It doesn't automatically open all tables, but it *does* apply to all files used by ElevateDB, even if you don't specify a buffer setting for them.  In such a case, the files are buffered using the default settings.

This is why the feature is called *global* file I/O buffering.

Tim Young
Elevate Software
www.elevatesoft.com

Thanks Tim,
I thought it might have been the Global aspect that caused ALL the tables to be opened.

On further research, i.e. late last night, I realised it was probably the Backup at 0430 that was 'opening' all the files.

The question now is, how long will the Server keep them open?

I had to Stop the EDB Server last night after the Users had all finished, when I went to physically Copy the files.

Regards,
Ian

A little aggravation from my Client this morning.
He went to do a 'Maint' - Verify/Repair/Optimise on the database this morning and it wouldn't let him because some 'Files were in use'.
Before allowing the Maint process I do a File level check to see if the files are 'in use' using this code..
{code}
function IsFileInUse(FileName: TFileName): Boolean;
var
 HFileRes: HFILE;
begin
 Result := False;
 if not FileExists(FileName) then
   Exit;
 HFileRes := CreateFile(PChar(FileName), GENERIC_READ or GENERIC_WRITE, 0, nil, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);
 Result := (HFileRes = INVALID_HANDLE_VALUE);
 if not Result then
   CloseHandle(HFileRes);
end;
{code}
As the EDB Server had the files open then the maintenance didn't go ahead.
This is the script running every morning at 0430.
{sql}
SCRIPT
BEGIN
EXECUTE IMMEDIATE 'BACKUP DATABASE "DBiWorkflow" AS "DBiWorkflow-Server Backup-' + CAST(CURRENT_DATE AS VARCHAR(10)) + '" TO
STORE "Backups" INCLUDE CATALOG';
END
{sql}
I suspect I need to release the tables after the Backup in the Server Job.
How do I do this please?
Regards & TIA,
Ian

On 4/8/2019 6:07 PM, Ian Branch wrote:
> He went to do a 'Maint' - Verify/Repair/Optimise on the database this morning and it wouldn't let him because some 'Files were in use'.
> Before allowing the Maint process I do a File level check to see if the files are 'in use' using this code..
> I suspect I need to release the tables after the Backup in the Server Job.
> How do I do this please?

I don't think you can - other than starting and stopping DBSRVR (which
you could easily do with the a schedules task or such after backup is done).

You can run the verify/repair/optimize using remote session and remove
the file open checking.

The whole idea of global I/O buffering is that DBSRVR engine is the only
one with access to db files so it can optimize buffering etc.


Raul

Raul wrote:

>>I don't think you can - other than starting and stopping DBSRVR (which
you could easily do with the a schedules task or such after backup is done).

Ahhh.  Now that's a thought.  I will look into it.

Thanks Raul,
Ian

Ian,

<< A little aggravation from my Client this morning.
He went to do a 'Maint' - Verify/Repair/Optimise on the database this morning and it wouldn't let him because some 'Files were in use'. >>

As Raul indicates, when you using global file I/O buffering, the EDB Server acts like a typical database server and exclusively opens all files.

However, you should still be able to perform normal EDB administrative functions, provided that you use a remote session to do so and don't try to access the configuration/databases using a local session.  This goes for backups, also.

The only exception to the above are store files - they are left alone and treated just like "files on a drive".

Tim Young
Elevate Software
www.elevatesoft.com