Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 13 total
Thread The dreaded #11013: Can't add an index in code.
Mon, Sep 3 2018 8:22 PMPermanent Link

Blake

Hi, fans of paleolithic software! =)

I have a scheme of migrating my users from my older structures where I check the DB for certain things and modify the tables. This works pretty well for adding/altering fields. I cannot get it to work for adding an index, however. I always get a 11013. I know my privatedir set up is okay because DBISAM is writing tons of things to it. Here is the code:

tblLookupCustomer.AddIndex('CUSTOMER_PHONE_OTHER','PHONE_OTHER', [ixCaseInsensitive], '', icNone);

I wasn't able to make the utility add this either, unless I ran it with elevated privileges, which worked. This does not work with my program, however. I believe I have de-activated anything with access to that table that might be locking, but no matter what I get:

DBISAM Engine Error # 11013 Access denied to table or backup file 'customer'
Tue, Sep 4 2018 2:17 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Blake


You need to look at the tables to see if they think they're being locked. I have a nice little utility called Unlocker which does just what its name suggests but will also tell you what locks have been found.

This

https://www.softpedia.com/get/System/System-Miscellaneous/Unlocker.shtml

is the one I have but there are a lot out there.


Roy Lambert
Tue, Sep 4 2018 9:08 AMPermanent Link

Raul

Team Elevate Team Elevate

On 9/3/2018 8:22 PM, Blake wrote:
> I wasn't able to make the utility add this either, unless I ran it with elevated privileges, which worked. This does not work with my program, however. I believe I have de-activated anything with access to that table that might be locking, but no matter what I get:

Utility related error is definitely related to file permissions
(Privatedir or actual table file) since it works when elevated.

This is where i would focus on.

Raul
Tue, Sep 4 2018 11:46 AMPermanent Link

Blake

Thanks, Roy, I'll check this out.
Tue, Sep 4 2018 11:52 AMPermanent Link

Blake

Thanks, Raul. The plot thickens.

I found the private directory setting for the utility: It was under the program's entry Program Files (which, sure, 15 years ago...). So that's why you need elevated permissions for the utility.

When I set it to the same directory my program is using—it just works, no need for elevated privileges. I think this means it's a locking issue.
Tue, Sep 4 2018 12:20 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Blake,

<< I found the private directory setting for the utility: It was under the program's entry Program Files (which, sure, 15 years ago...). So that's why you need elevated permissions for the utility. >>

Which "utility" are you referring to ?  The latest versions of the DBISAM Database System Utility (and all DBISAM 4.x versions of the utility going back at least the last decade) default to the user's temporary files directory.

You can verify this very easily: just rename the dbsys.ini file in the following directory to dbsys.ini.old:

C:\Users\<UserName>\AppData\Local\Elevate Software\Database System Utility

and restart the DBISAM Database System Utility.  You will see that the private directory defaults to the user's temporary files directory.

<< When I set it to the same directory my program is using—it just works, no need for elevated privileges. I think this means it's a locking issue. >>

It's a file/folder permissions issue.  Any time you see an "Access denied" and the error message includes a temporary table name, it's an issue with the private directory and having write permissions for that directory.

Tim Young
Elevate Software
www.elevatesoft.com
Sat, Sep 15 2018 3:54 PMPermanent Link

Blake

Tim Young [Elevate Software] wrote:

<<Which "utility" are you referring to ?  The latest versions of the DBISAM Database System Utility (and all DBISAM 4.x versions of the utility going back at least the last decade) default to the user's temporary files directory.>>

OK. The issue arose because when I try to add an index using the utility I get the 11013. If I run the DBSU as an administrator, I do not.

>>You can verify this very easily: just rename the dbsys.ini file in the following directory to dbsys.ini.old:

What I see currently is that it is set at:

Private Directory=C:\Users\<user name>\<my project directory>\temp

>>and restart the DBISAM Database System Utility.  You will see that the private directory defaults to the user's temporary files directory.

Confirmed. And when the default directory is used, there is no 11013 when trying to alter the table.

>>It's a file/folder permissions issue.  Any time you see an "Access denied" and the error message includes a temporary table name, it's an issue with the private directory and having write permissions for that directory.

I would've guessed that being under the "Users" directory would've been enough to allow access to the current user (i.e., "\Users\me\whatever") but I guess not.

Since I was unaware of this setting and still don't know how to change it (short of going into that .INI file I was previously unaware of), how could that value have been set to:

Private Directory=C:\Users\<user name>\<my project directory>\temp

In the first place?

And more importantly, is there any reason to have the utility point to the same temp directory? I believe when multiple users are on this software they're all running from the same .EXE on the same directory on the network.

===Blake==
Sun, Sep 16 2018 7:37 PMPermanent Link

Raul

Team Elevate Team Elevate

On 9/15/2018 3:54 PM, Blake wrote:
>
> I would've guessed that being under the "Users" directory would've been enough to allow access to the current user (i.e., "\Users\me\whatever") but I guess not.
>

Yes from OS perspective but as a user you can change those permissions
any way you like so "\Users\me\whatever" might be read-only and
"\Users\me\something" if full permissions.

> Since I was unaware of this setting and still don't know how to change it (short of going into that .INI file I was previously unaware of), how could that value have been set to:
>
> Private Directory=C:\Users\<user name>\<my project directory>\temp
>

In DBSYS it's under File->Options->Global Tab and the "Private
Directory" setting so somebody must have changed it at some point.

This setting used to blank i think and changed to this new default in
4.30 B5 so depending how far back your software goes maybe this was
changed back when it was blank to this user setting.

> And more importantly, is there any reason to have the utility point to the same temp directory? I believe when multiple users are on this software they're all running from the same .EXE on the same directory on the network.

Depending on what they do with the utility there are performance
benefits from having the temp files created locally (vs shared network
share).

Raul
Sun, Sep 16 2018 10:31 PMPermanent Link

Blake

Raul wrote:

<<Yes from OS perspective but as a user you can change those permissions
any way you like so "\Users\me\whatever" might be read-only and
"\Users\me\something" if full permissions.>>

I haven't, personally.

>>In DBSYS it's under File->Options->Global Tab and the "Private
Directory" setting so somebody must have changed it at some point.<<

Well, I guess I must've done it and forgot about it.

>>This setting used to blank i think and changed to this new default in
4.30 B5 so depending how far back your software goes maybe this was
changed back when it was blank to this user setting.<<

The version I initially installed was 4.30 B7. I later udgraded to 4.45.

>>Depending on what they do with the utility there are performance
benefits from having the temp files created locally (vs shared network
share).<<

None of our customers use the utility, as far as I know. They experience slowdowns in the app, sometimes, which I don't understand, since the data (in aggregate) in their installation is about 50MB.

===Blake===
Mon, Sep 17 2018 3:40 PMPermanent Link

Raul

Team Elevate Team Elevate

On 9/16/2018 10:31 PM, Blake wrote:
>
> None of our customers use the utility, as far as I know. They experience slowdowns in the app, sometimes, which I don't understand, since the data (in aggregate) in their installation is about 50MB.
>

Do you set the session private directory in your app code or rely on
default value  ?

Using network file sharing in general can be slow - i would try to track
down is slow and when.
if you search this newsgroups there are number of things to check inm
case of F/S mode. Making sure AV does not scan files, that server power
plan does not spin down disks and most importantly that users are on
good connections (wired, slow wireless clients can cause issues with
windows file sharing for every user, etc)

Raul
Page 1 of 2Next Page »
Jump to Page:  1 2
Image