Specifying the location for the LDB file. 1

[Phooey]

Is there any known way to specify the location for the locking file?

I ask this question because of a sizeable database I recently written (3mill rows @ 800Mb). Networks will not place the database on the server because it will take up over half of the remaining server space, the local PC's do not have enough room to store the data and the client is unwilling to purchase more hardware for the sake of one database.

The data contained in the database is static archived data and as such, will not change. The users only have read permissions for the database, so the database should not change in size.

After the client heard about the size of the database, they would like to place the database onto a CD, so it would seem that I now have two options: either to use Re-Writeable CD or to try to find a way to change the location of the LDB file.

Any help would be much appreciated.



Phooey
Andrew.j.harrison@capgemini.co.uk
Otherwise known as Windy Bottom.

 

[THoey]

I have a white paper from Microsoft that covers Jet 2.x and 3.x that specifically says:

One .LDB file is always created for every Microsoft Jet database file that is connected in a shared mode. The .LDB file always retains the same name as the database that was opened (for example, NWIND.MDB always has a NWIND.LDB), and the .LDB file will always be in the same directory as the database.


You never know, MS has lied before. I can send it to you if you like.

Let me know...


Terry M. Hoey
th3856@txmail.sbc.com

Ever notice that by the time that you realize that you ran a truncate script on the wrong instance, it is too late to stop it?

 

[MichaelRed]

A possible alternative.

Place the "Archive" database on the CD - as requested. but in a different file format (which Ms. Acceess 'knows", such as .DBF). Open the table as a link. Since it is not an ".MDB", there is no need for an ".LDB"?



MichaelRed
mred@duvallgroup.com
There is never time to do it right but there is always time to do it over

 

[Shep]

Phooey,
As Michael says, why not split your MDB in two and put the data on a CD and keep the front-end forms + queries etc on the user's hard-drive?
You dont have to create a DBF file or anything like that - just have one MDB for the data and one for the software with all the tables linked.
Obviously, if more than one user wants access (little 'a') you'll need to cut more than one CD.

I have done this several times for Payroll archives with no problem.

Shep

 

[MichaelRed]

Shep,

The reason for the format change is to avoid the (attempt to) create(ion) of the LDB file. It WILL appear where ever the MDB file is (on the CD - where it can not be created).

On the other hand, the split data will probably get out of sync w/ the forms/reports fairly quickly, and then there will be some other difficulties. But this will hapen with almost every 'archived' data set. Being on a CD will just make it worse, as the table structure cannot be (easily) changed.



MichaelRed
mred@duvallgroup.com
There is never time to do it right but there is always time to do it over

 

[Phooey]

MichaelRed, that's a very good idea and one that I had not thought of...

I'll give it a go...

Phooey
Andrew.j.harrison@capgemini.co.uk
Otherwise known as Windy Bottom.

 

[Shep]

Michael,
Like I said in my post - I have done this several times with various payroll archives. The LDB file is created wherever the front-end MDB file is (eg C:\PayArch\) - it makes no odds where the linked tables are (eg D:\On_A_CD\).
I even had one instance where I had 7 years worth of data (1.9Gb) in 7 MDB files on 4 CD's with a single (3Mb) MDB file on the user's hard drive - saved space on the user's machine / network but meant he had to keep swapping CD's to see different years.

Shep

 

[Phooey]

Shep, I don't mean to doubt your experience, but what I have seen when the front end is opened, it creates an ldb file for the front end. But when the front end displays records from the back end, another ldb file is created for the back end as well.

Are you trapping the error returned in some way and discarding it?

I'm just curious because, as I say, that's the way I've seen it working. All be it, I have only implemented databases on the network so far. In fact, this is precisely the reason why the users still have delete privileges on the network drives.



Phooey
Andrew.j.harrison@capgemini.co.uk
Otherwise known as Windy Bottom.

 

[Shep]

Phooey
Like you say, when you open the front-end MDB you get a corresponding LDB. But you never open the other MDB file - the tables are all linked (File >Get External Data > Link Tables...).
No errors, no problems & only one LDB file.

Shep

 

[Phooey]

Shep, every database I've implemented so far has been split into the front / back end and opening the front end will create a ldb file for the front end. The back end is referred to via linked tables in the front end, however, when the front end displays records from the back end, the ldb for the back end is created.

Once the corresponding form is closed then the back end ldb is destroyed.

In your forms, are the records bound to the form or are the controls unbound and populated from a recordset?

Phooey
Andrew.j.harrison@capgemini.co.uk
Otherwise known as Windy Bottom.

 

[Shep]

Phooey,
In the example I mentioned above, all the controls were bound to an underlying record source.
I've just done a test on a linked system on our network + you're right about the second LDB file being created (never noticed it before).
BUT - I have also just tried the same thing using linked data from a CD + it works fine - presumably if Access can't create an LDB it just carries on regardless.

Shep