Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 10 of 13 total |
Vista, UAC and #11013 |
Wed, Apr 1 2009 12:36 AM | Permanent Link |
Pat | Hi all,
I have a v4 application that runs OK in XP and also in Vista with UAC turned off. When UAC is turned on, I get Engine Error #11013 Access Denied to table or backup file '6270' (the value in the '' changes each time the app starts ie 35480,37000...) I get the error between the main form's Form.Create and Form.Show events. My .exe uses folder C:\MyApp and data is in C:\MyApp\Data. I tried running from C:\Users\Public\MyApp & C:\Users\Public\MyApp\Data but still the same. The only code in the Form.Create that I can see may cause the problem is: if DidNotFindData = False then // change Database directory IF data folder is found begin DBISAMDatabase1.Connected := False; DBISAMDatabase1.Directory := strDataDirectory; DBISAMDatabase1.Connected := True; end; I browsed this ng & saw a possible solution as: TDBISAMEngine.CreateTempTablesInDatabase property to True but when I put this code in my Form.Create I get no property called CreateTempTablesInDatabase. My app uses Session & Database components. Any ideas on how to troubleshoot this? Many thanks. Regards, Pat |
Thu, Apr 2 2009 5:45 AM | Permanent Link |
Fernando Dias Team Elevate | Pat,
> Denied to table or backup file '6270' (the value in the '' changes > each time the app starts ie 35480,37000...) File names like of that are for sure temporary files that DBISAM creates when a canned query is opened. Those temporary files are created in the directory specified by the TDBISAMSession.PrivateDir property, not in the database directory. Your application is certainly trying to open a canned query at startup and thus trying to create a temporary file in a directory where you do not have the appropriate permissions in Vista and that's why you are getting this error message. You must set TDBISAMSession.PrivateDir to a directory where you have write permissions. > I browsed this ng & saw a possible solution as: > TDBISAMEngine.CreateTempTablesInDatabase property to True Maybe or maybe not - CreateTempTablesInDatabase property only controls the location of temporary tables created by ALTER, OPTIMIZE or UPGRADE operations, so unless your application is executing one of this operations at startup, I would say it's not the solution. > but when I put this code in my Form.Create I get no property called > CreateTempTablesInDatabase. My app uses Session & Database components. The CreateTempTablesInDatabase property was only introduced in version 4.15 - what version are you using? -- Fernando Dias [Team Elevate] |
Fri, Apr 3 2009 1:17 AM | Permanent Link |
Pat | Hi Fernando,
> You must set TDBISAMSession.PrivateDir to a directory where >you have write permissions. that fixed me up!! >The CreateTempTablesInDatabase property was only introduced in version >4.15 - what version are you using? 4.21 Build 11. Not to worry, got it working OK now. Many thanks. Pat |
Tue, Apr 6 2010 10:14 AM | Permanent Link |
NickH | Hi,
Major headache with this - only under Vista and Win7 with UAC. My application stores its DBISAM tables in C:\ProgramData\<myapp> which works fine until it tries to use AlterTable when it gives error #11013. I am using Engine.CreateTempTablesInDatabase := true; which works because it creates temp files in the right folder but the problem seems to be that the application does not have permission to rename the old table files to .dbk, .ibk, etc. The table files in C:\ProgramData\<myapp> only have user permission to Read&execute and Read. If I manually add write permission for Users then AlterTable works once, but then the new, altered table files are back to only Read&execute and Read permissions so AlterTable wont work a second time. Using Alter Table in the Database System Utility produces the same error. I'm using DBISAM VCL V4.29 B3 What's the best plan to get around this? |
Tue, Apr 6 2010 2:17 PM | Permanent Link |
Raul Team Elevate | Nick,
You need to give explicit permissions during install for all users (or Everyone) if you wish to use the C:\ProgramData\<myapp> location. Specifically only the owner/creator and admin have write access. See MS docs here for more details: http://msdn.microsoft.com/en-us/library/ms995853.aspx Specifically look for this (unless you plan to submit you app for certification you can ignore the Questionnaire part ): ======================================= # CSIDL_COMMON_APPDATA This folder should be used for application data that is not user specific. For example, an application may store a spell check dictionary, a database of clip-art or a log file in the CSIDL_COMMON_APPDATA folder. This information will not roam and is available to anyone using the computer. By default, this location is read-only for normal (non-admin, non-power) Users. If an application requires normal Users to have write access to an application specific subdirectory of CSIDL_COMMON_APPDATA, then the application must explicitly modify the security on that sub-directory during application setup. The modified security must be documented in the Vendor Questionnaire. ======================================= Raul |
Tue, Apr 6 2010 2:42 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Nick,
To add to what Raul said, this is the entry that we use with Inno Setup for our ElevateDB installations under the "Dirs" section: Entry('Name','"{commonappdata}\Elevate Software"; Permissions: admins-full system-full users-readexec'); The ElevateDB Server uses the common app data directory for storing its .ini configuration file, so it must make sure that the proper permissions are present. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Apr 7 2010 2:46 AM | Permanent Link |
Iztok Lajovic (1) | Pat,
the best way IMHO is not to use subdirectory of C:\ProgramData\... at all but to store entire application and all data somewhere else. For all our application we create our own directory 'C:\kres\<application name>\...' ('kres' is our company short name) either locally or on server side. In separate directories we put program(s), data, archives and so on. Till now we had not experienced any trouble with UAC. Regards Iztok Lajovic KreS, Kreativni sistemi, d.o.o. |
Wed, Apr 7 2010 7:58 AM | Permanent Link |
NickH | Hi guys,
Thanks for the replies. Raising the permissions on the C:\ProgramData\<myapp> folder for "Everyone" to "Generic_all" during installation did help get over the #11013 error. But it turned out that virtualization was copying updated database files into the VirtualStore anyway. How stupid is that? Why bother having an AppData folder if Windows continues to treat it like the "Program files" folder? I agree with Iztok. It is pointless trying to use the "safe" Windows folders specified by Microsoft. Much better to create your own data folder in C:\ (or at least WindowsVolume). All the problems go away. That's what I'm going to do. |
Wed, Apr 7 2010 10:32 AM | Permanent Link |
Robert Kaplan | <NickH> wrote in message news:E90837A2-B2B1-43D8-9F05-D6EFB006AE04@news.elevatesoft.com... > > I agree with Iztok. It is pointless trying to use the "safe" Windows > folders specified by Microsoft. Much better to create your own data folder > in C:\ (or at least WindowsVolume). All the problems go away. That's what > I'm going to do. > Way to go. One needs an attorney to check all the Windows permissions and issues. Just install in your own folder, and voila, just like DOS. Funny and sad how easy it is to circumvent the Windows "security". Robert |
Wed, Apr 7 2010 12:17 PM | Permanent Link |
Malcolm Taylor | Hi Nick
I think you will find that including an appropriate manifest is the 'correct' way to disable Virtualisation. Like Tim, I use Innosetup for my installations and it automatically includes a suitable manifest and makes it a breeze. Inno's newsgroups have regular postings about this and related issues which attract replies from people, much better qualified than I am, advising strongly against disregarding the recommended installation guidelines. As well as covering issues such as security and unusual configurations, they point out that it is one thing to ignore the guidelines on your own computers but quite another to do so on others', specially if you are supplying corporate customers. I think you were nearly there and that a little further investigation will solve your current 'problems' and set you up for a smoother ride into Windows 8 .... Malcolm -- |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Friday, April 19, 2024 at 07:09 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |