Accessing access DB from another server?

Results 1 to 2 of 2

Thread: Accessing access DB from another server?

  1. #1
    Join Date
    Dec 1969

    Default Accessing access DB from another server?

    I have two servers. Server A has IIS and has an asp page hitting an access DB. Works great.<BR><BR>I now need Server B to hit the same access DB. The ASP page is the same and it references a system DSN for the connection. The DSN is on both servers and setup correctly.<BR><BR>But it doesn&#039;t work...can&#039;t connect to DB via the code. Is it possible to even do this?<BR><BR>I read something that said the db (if access) must be that true? <BR><BR>Any ideas?

  2. #2
    Join Date
    Dec 1969

    Default Access is *not* a server...

    So there is no database to "connect" to. With MySQL or SQL Server or Oracle, the database is always accessed via a server, so all you have to do is connect to that server, usually via TCP/IP or a named pipe or or or.<BR><BR>Access, on the other hand, is really just a file in the filesystem. And you get data in and out of it by using code that co-resides in your process space (in a DLL). And that code operates by simply opening up the ".mdb" file and pulling in (and writing out) data.<BR><BR>So that means that a system with multiple processes sharing one Access DB is already fraught with danger: If process A (say the ASP engine on machine A) is busily reading from and writing to that DB file, then how can process B do the same? The (somewhat hokey) answer is provided in the form of a "lock" file; that&#039;s what those ".ldb" files you&#039;ve seen in the directory where your ".mdb" files sit are doing.<BR><BR>Hopefully, you can see where we are going with this. The *only* way to share an Access db is...share the .mdb file! And, at least as importantly, share the .ldb file. <BR><BR>Which means, essentially, sharing the directory where the DB resides (and all the files in it).<BR><BR>But read what I wrote above: Access was never really designed for multiple simultaneous processes. It does a pretty darned good job of handling a single writer with multiple readers, but it can get really bogged down (waiting for permissions via the .ldb file) when you are writing to it from multiple processes. If at all possible, segment your usage of the DB. Try to ensure that all ASP pages served by machine B use the DB as read-only. You&#039;ll still occasionally get contention, but it will be minimized.<BR><BR>Finally, consider upgrading to a true server-based DB. If you aren&#039;t ready to take the plunge to SQL Server, try MySQL. It&#039;s free, but then it doesn&#039;t have the support (and features!) that SQL Server does.<BR><BR>

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts