Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 13 total
Thread Vista, UAC and #11013
Wed, Apr 1 2009 12:36 AMPermanent 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 AMPermanent Link

Fernando Dias

Team Elevate 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 AMPermanent Link

Pat
Hi Fernando,

> You must set TDBISAMSession.PrivateDir to a directory where
>you have write permissions.

that fixed me up!!  Smile

>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 AMPermanent 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 PMPermanent Link

Raul

Team Elevate 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 Smile ):

=======================================
# 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 AMPermanent 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 AMPermanent 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 AMPermanent 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 PMPermanent 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 ....  Surprised

Malcolm
--
Page 1 of 2Next Page »
Jump to Page:  1 2
Image