Hi!

Ok, we have had a weird problem with some customers, and today we have noticed the origin of the problem.

The problem:
- Customer PC. Application installed in two (or more) pc. Everything ok. Both C/S or shared folder scenarios.
- Customer repairs DBISAM tables with our repair utility (verify->repair and optimize)
- dbisam files (.dat, .idx and .blb) lose their original permissions. Now Client PC can't connect to Server (Access Denied).

What we have noticed:
- The problem occurs after calling OptimizeTable(). Even with a simple testing app created for that mission.
- After optimizetable, idk, bbk and dbk files appears. THOSE FILES has the correct file permission, BUT...
- Original files (dat, idx...) lose the original permissions, so client pcs can't find them.
- We have to select all files, properties -> security -> and change the permissions again.

I don't know what is the cause of the problem, and why optimizetable is causing this. I don't actually know if it is a DBISAM related issue or if it happens due to a Windows permissions handling problem.

Deactivating UAC makes no effect. It happens even on XP.
We have customers reporting this on XP, Windows 7 and Windows 8.1

We have reproduced this in our PCs at work, but no screenshot can explain this.

Do you know what clould be the reason?

Thanks a lot

Luis C.

On 4/23/2015 11:55 AM, Luis Conception Gonzalez wrote:
> What we have noticed:
> - The problem occurs after calling OptimizeTable(). Even with a simple testing app created for that mission.
> - After optimizetable, idk, bbk and dbk files appears. THOSE FILES has the correct file permission, BUT...
> - Original files (dat, idx...) lose the original permissions, so client pcs can't find them.
> - We have to select all files, properties -> security -> and change the permissions again.
> Do you know what clould be the reason?

What's your session PrivateDir setting ?

Raul

Ok, after some research, the problem is ONLY with DBISAM 4.40 B1

Even using Optimize Table option from DBSYS utility, the files lose their permissions, so no matter which is my PrivateDir...

I installed DBISAM ADD 4.30. Optimize Tables. Works OK
Then I installed DBISAM ADD 4.35. Optimize Tables. Works OK. Files don't lose permissions.
Then the same with 4.39. Optimize. OK
NOW with 4.40 B1. Optimize. Files lose permissions!!!

Then if I use 4.39 dbsys with those files, permissions are restored and working again as expected!!

I'm afraid there's a problem with OptimizeTable() in 4.40 B1.

Luis C.


Raul wrote:

On 4/23/2015 11:55 AM, Luis Conception Gonzalez wrote:
> What we have noticed:
> - The problem occurs after calling OptimizeTable(). Even with a simple testing app created for that mission.
> - After optimizetable, idk, bbk and dbk files appears. THOSE FILES has the correct file permission, BUT...
> - Original files (dat, idx...) lose the original permissions, so client pcs can't find them.
> - We have to select all files, properties -> security -> and change the permissions again.
> Do you know what clould be the reason?

What's your session PrivateDir setting ?

Raul

On 4/23/2015 1:01 PM, Luis Conception Gonzalez wrote:
> Ok, after some research, the problem is ONLY with DBISAM 4.40 B1

Might be caused by this then :

http://www.elevatesoft.com/incident?action=viewaddr&category=dbisam&release=4.40&incident=4068

Try setting your "CreateTempTablesInDatabase" to True if it's false.


Raul

Hi, Raul...

I don't think that's the cause, because that incident report was reported for 4.35 and solved in 4.40, but I have the problem ONLY with 4.40. (4.35, 4.39, etc. work correctly).

Also, I'm not using any DBISAMEngine component. How and where can I set it to True?

Luis C.


Raul wrote:

On 4/23/2015 1:01 PM, Luis Conception Gonzalez wrote:
> Ok, after some research, the problem is ONLY with DBISAM 4.40 B1

Might be caused by this then :

http://www.elevatesoft.com/incident?action=viewaddr&category=dbisam&release=4.40&incident=4068

Try setting your "CreateTempTablesInDatabase" to True if it's false.


Raul

On 4/23/2015 1:59 PM, Luis Conception Gonzalez wrote:

Luis,

> I don't think that's the cause, because that incident report was reported for 4.35 and solved in 4.40, but I have the problem ONLY with 4.40. (4.35, 4.39, etc. work correctly).

If i'm reading the incident correctly then prior to 4.40 OptimizeTable
always created temp files in data directory (ignoring privatedir).

Starting in 4.40 the Optimizetable honours the setting this entry is set
to - default value for this is false so any temp tables are in the
Private Dir folder so they would likely retain permissions from it.

> Also, I'm not using any DBISAMEngine component. How and where can I set it to True?

There is always a default engine so you can just reference that (you
need to make sure dbisamtb unit is in uses clause) :

engine.CreateTempTablesInDatabase := true;

or just drop engine component if you prefer to use the component direct.



Raul

Hi, Raul...

You are right. I misunderstood the incident report.
I have changed it to TRUE and now it's working correctly.

Thanks!


Raul wrote:

On 4/23/2015 1:59 PM, Luis Conception Gonzalez wrote:

Luis,

> I don't think that's the cause, because that incident report was reported for 4.35 and solved in 4.40, but I have the problem ONLY with 4.40. (4.35, 4.39, etc. work correctly).

If i'm reading the incident correctly then prior to 4.40 OptimizeTable
always created temp files in data directory (ignoring privatedir).

Starting in 4.40 the Optimizetable honours the setting this entry is set
to - default value for this is false so any temp tables are in the
Private Dir folder so they would likely retain permissions from it.

> Also, I'm not using any DBISAMEngine component. How and where can I set it to True?

There is always a default engine so you can just reference that (you
need to make sure dbisamtb unit is in uses clause) :

engine.CreateTempTablesInDatabase := true;

or just drop engine component if you prefer to use the component direct.



Raul