Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 10 of 13 total |
The dreaded #11013: Can't add an index in code. |
Mon, Sep 3 2018 8:22 PM | Permanent 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 AM | Permanent Link |
Roy Lambert NLH Associates 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 AM | Permanent Link |
Raul 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 AM | Permanent Link |
Blake | Thanks, Roy, I'll check this out.
|
Tue, Sep 4 2018 11:52 AM | Permanent 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 PM | Permanent 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 PM | Permanent Link |
Raul 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 PM | Permanent 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 PM | Permanent Link |
Raul 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 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Tuesday, May 7, 2024 at 06:25 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |