I've installed SQL Anywhere in a custom directory and added
iAnywhere.Data.SQLAnywhere.dll there.

The .NET program seems to start up and continue to run fine,
but an annoying error pops up:
"SQL Anywhere ADO.NET Data Provider requires access
permissions of one of the following directories:
1. System temporary directory (c:\windows\temp)
2. Current working directory (c:\windows\system32)
3. SQL Anywhere ADO.NET Data Provider assembly directory
(directory where my app and the
iAnywhere.Data.SQLAnywhere.dll are installed)"

I'm running the program as a service under LocalSystem. I'm
not sure how or where I would give the data provider access
permissions. What is it looking for here? What does this
error really mean I'm supposed to do?

Actually it the account the service is running under that needs
to be granted access permissions. Grant the SYSTEM account
access to the %temp% directory should be sufficient.


<ints> wrote

The computers that are having this problem are all systems
that are not joined to any domain, and only have local
filesystems. We can't see any reason the LocalSystem
account wouldn't have access to those folders, and the
Security tab doesn't show up when you aren't on a domain.

Are there more specific steps you could recommend in this
case? We're kind of at a loss as to how we can accomplish
this.

The local SYSTEM account has no credentials
per se. It usually gains access via membership
in the group Everyone and one of the first
security measures people consider is revoking
that membership.

So just give this a try. Right-Mouse-Click on
your C:\windows\temp directory from Windows
explorer and select Properties. Then under
the Security tab, grant full access to the
account SYSTEM or the group Everyone.
Then reboot and check how it works after
doing that.

Either way, the account your service is running
under does not have permissions. If you cannot
figure out how Microsoft file system security
is working against you, then you may need to
contact your computer vendor (or Microsoft).


<ints> wrote

For anybody else who experiences this problem-- SYSTEM did
have permissions in those directories. Upgrading to EBF
3931 seems to have fixed the problem, although this isn't
mentioned as a bug in the readme... maybe this:
================(Build #3923 - Engineering Case
#580607)================

User Impersonation on IIS caused Win32Exception "Access is
denied". This has been fixed.

had a side effect for us?

Thanks for that update Jen.

I hadn't considered this might be related to IIS
operation (and specifically User Impersonation);
though in hindsight that may have seemed to be
an obvious 'likely' scenario.

<Jen> wrote

Well, no sooner than I open my mouth... the tenth or so time
I rebooted, it showed up again. And then started showing up
on first reboot when I tried from scratch again.

We're not using IIS, so not sure.

The only thing I can think of is that we are running into
some kind of dll-extraction race condition scenario. Seven
NET services all trying to extract that file out... ProcMon
doesn't show any ACCESS DENIED problems, but it shows a lot
of NAME COLLISION.

We're going to open a support case because this has been in
investigation for too long and we need to wrap this release
up Will post when we figure out what the problem was.

Sybase Support has confirmed that we are indeed running into
a race-condition scenario with our services. This should be
fixed in the next EBF.

Jen