David
Thu May 08 19:29:18 CDT 2008
On May 8, 7:31=A0am, MarcusB <marc...@llunet.se> wrote:
> ONe strange thing which I discovered is that connection with 1. and 2 is
> using different users respectivelly. But I could not find what users.
>
> 1.
> objConn.ConnectionString =3D "Provider=3DMicrosoft.Jet.OLEDB.4.0;Data
> Source=3DF:\www\RD\Internt\RoomBooking\EventCalendar\Database\users.mdb;Pe=
rsi=ADst
> Security Info=3DFalse"
>
> 2.
> DRIVER=3D{Microsoft Access
> Driver(*.mdb)};DBQ=3DF:\www\RD\Internt\RoomBooking\EventCalendar\Database\=
use=ADrs.mdb
>
> Marcus
>
> What else can I check? MarcusB wrote:
>
>
>
> > Both are using the same Anonymous Authentication: Application pool
> > identity and both are in the same application.
> > Which user is than. What user account is used if you run Application
> > pool identity?
>
> > Marcus
>
> > Daniel Crichton wrote:
> >> It sounds like it could be a permissions issue - what error are you
> >> getting? If each application is using a different user account for
> >> security you need to ensure that these accounts have read/write access
> >> to the Temp folder.
>
> >> Dan
>
> >> MarcusB wrote =A0on Thu, 08 May 2008 15:04:45 +0200:
>
> >>> I just check and the ODBC driver for Access is working on one
> >>> application and in the other in different folder is not working. Why?
> >>> The second folder is on the same site the only on different folder.
>
> >>> Marcus
>
> >>> =A0 one aplication
> >>> Daniel Crichton wrote:
> >> =A0>> The first is using the JET OLE DB driver, the second is using the=
> >> =A0>> ODBC =A0driver for Access. =A0It may be that you don't have the O=
DBC
> >> =A0>> driver installed, =A0only the JET OLE DB driver.
>
> >> =A0>> Dan
>
> >> =A0>> MarcusB wrote =A0on Thu, 08 May 2008 11:50:16 +0200:
>
> >> =A0>>> Somehow I manage , I enable 32bit applications:
> >> =A0>>> But what is a difference in
>
> >> =A0>>> objConn.ConnectionString =3D "Provider=3DMicrosoft.Jet.OLEDB.4.0=
;Data
> >> =A0>>> Source=3DF:\www\RD\Internt\RoomBooking\EventCalendar\Database\us=
ers.
> >> =A0>>> mdb;
> >> =A0>>> Persist Security Info=3DFalse"
>
> >> =A0>>> =A0 DRIVER=3D{Microsoft Access
> >> =A0>>> Driver(*.mdb)};DBQ=3DF:\www\RD\Internt\RoomBooking\EventCalendar=
\
> >> =A0>>> Database\
> >> =A0>>> users.mdb
>
> >> =A0>>> The first one is working and the second one is not.
>
> >> =A0>>> Marcus
>
> >> =A0>>> MarcusB wrote:
> >> =A0>>>> Hi Ken,
> >> =A0>>>> It seems that =A0string is valid, I got response like:
> >> =A0>>>> DRIVER=3D{Microsoft Access
> >> =A0>>>> Driver(*.mdb)};DBQ=3DF:\www\RD\Internt\RoomBooking\EventCalenda=
r\
> >> =A0>>>> Database\users.mdb
>
> >> =A0>>>> THe PAth to users.mdb is right:
> >> =A0>>>> F:\www\RD\Internt\RoomBooking\EventCalendar\Database\users.mdb
>
> >> =A0>>>> What else can I check?
>
> >> =A0>>>> Marcus
> >> =A0>>>> Ken Schaefer wrote:
> >> =A0>>>>> Change your .inc file to be:
>
> >> =A0>>>>> objConn.ConnectionString=3D"DRIVER=3D{Microsoft Access Driver(=
*.mdb)};
> >> =A0>>>>> DBQ=3D" & dbpath
>
> >> =A0>>>>> ' Add these lines
> >> =A0>>>>> Response.Write(objConn.ConnectionString)
> >> =A0>>>>> Response.Flush
> >> =A0>>>>> Response.End
>
> >> =A0>>>>> and verify that your connection string is still actually valid=
.
>
> >> =A0>>>>> Cheers
> >> =A0>>>>> Ken- Hide quoted text -
>
> - Show quoted text -
Pragmatically:
http://blogs.msdn.com/david.wang/archive/2005/06/29/IIS_User_Identity_to_Run=
_Code_Part_2.aspx
Empirically:
Use Process Monitor from SysInternals.com to see what user identity is
accessing the files on disk.
There is a huge difference between 32bit and 64bit Windows, with lots
of compatibility switches that may need to be tweaked, depending on
the application. Unless you have specifically tested your application
in 64bit Windows, I would suggest starting with 32bit Windows. Using
32bit Application Pools in IIS can be a quick fix, but you need to be
weary of how 32bit compatibility on 64bit Windows works because it can
be subtle.
Lots of things have changed since IIS5, starting with the security
model -- IIS5 ran as LocalSystem had access to everything, so you
never saw access denied -- but when exploited by hackers, they never
saw access denied either. IIS6 and later run as unpriviledged Network
Service, which has access to very few things, so you can often see
access denied -- but if exploited by hackers, they frequently saw
access denied as well.
I am just warning you that this may not be your biggest obstacle to
running your website from 32bit IIS5 to 64bit IIS7, so please set your
expectations appropriately.
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//