Links

quest

Member
Local time
Today, 10:23
Joined
Nov 26, 2024
Messages
39
Hi,
Is there a way to check and repair links to pdf files. I don't mean manually one by one. Thanks
 
I read your post. I know nothing about your problem, except that it involves links to pdf files.
Cheers,
 
Might depend on how you broke them.
 
I read your post. I know nothing about your problem, except that it involves links to pdf files.
Cheers,
I have a filed (link) that opens a pdf file when you click it. when folders are moved or from some other reaseon is possible link don't ppen the pdf file. If it is big database checking one link at the time is too much time consuming. is there some faster way.
 
Are you looking to FIND broken links? If so, iirc you use the Dir() function to verify it exists.
If they are broken, do you have enough information to know how to fix them? Do you keep a table of directory changes?
 
Are you looking to FIND broken links? If so, iirc you use the Dir() function to verify it exists.
If they are broken, do you have enough information to know how to fix them? Do you keep a table of directory changes?
yes broken links. sometimes i do sometimes don't but even if i have too much fields to repair especially when folders are moved.
 
A lot depends on how your file folders are set up and how your Pdf's are named.

I tend to have one main folder with subfolders. The subfolders are named for each client and hold just the files related to that client. That way I don't have to store the path to any file or worry that any 2 files have the same name.

You can use filesystemobject to iterate through folders and get file names and paths.
 
A lot depends on how your file folders are set up and how your Pdf's are named.

I tend to have one main folder with subfolders. The subfolders are named for each client and hold just the files related to that client. That way I don't have to store the path to any file or worry that any 2 files have the same name.

You can use filesystemobject to iterate through folders and get file names and paths.
same with me too. folders with subfolders. not same names at least not in same folder. my database was on stcik. i made changes to database so i have to change some folders. also there was some stick failure. I repair it. database was saved only problems with links.
 
yes broken links. sometimes i do sometimes don't but even if i have too much fields to repair especially when folders are moved.
Are you saving the path, name, size, and date in a table?
If not, you'll have problems the moment you admit more than one PDF has the same file name. If all file names are unique, as other's have said you can search for them. If they are not and you don't have a way to make sure which is which, I'd advise looking in to that first.
 
Are you saving the path, name, size, and date in a table?
If not, you'll have problems the moment you admit more than one PDF has the same file name. If all file names are unique, as other's have said you can search for them. If they are not and you don't have a way to make sure which is which, I'd advise looking in to that first.
something like this 2025\101-150\104\03-104(1).pdf and i know exactly by the path which file it is and which field should go. i can repair manually each and I already have some repaired just need too much time this way.
 
The hyperlink field - when being edited by keyboard/screen in design mode, or by program via VBA - is just text. You can manipulate the parts easily enough. It's only a hyperlink when not in design view. The way I would do this is to use FileSystemObject to pick out the file's name from its original value, then use FSO's search abilities to find the file of that name, then replace the text of the hyperlink with the whole path & name of what you found.
 
If I move database and pdf files from usb to hard disk links wont work again?

That is an "It depends" question. This DB sounds like it isn't shared with anyone and in fact might not even be split into a front-end/back-end pair.

If this is NOT a split DB then there is a decent chance that it doesn't care where it runs. But if where it LOOKS for its .PDF files is hard-coded, you might need to edit something in the code. If your method of operation is to just point it somewhere and let it browse from there, it might be OK as-is without modification.

IF (and ONLY IF) this IS a split DB with front-end and back-end files, you would have to adjust the links to the back-end file from the front-end. However, this would only have to be done once and saved. The way to do that is to open the DB and switch to the Database Tools ribbon to find External Data. Browse around in there to find the tool to relink the tables. You can select via check-boxes all the tables to be relinked in a single action, so it is easy-peasy.
 
That is an "It depends" question. This DB sounds like it isn't shared with anyone and in fact might not even be split into a front-end/back-end pair.

If this is NOT a split DB then there is a decent chance that it doesn't care where it runs. But if where it LOOKS for its .PDF files is hard-coded, you might need to edit something in the code. If your method of operation is to just point it somewhere and let it browse from there, it might be OK as-is without modification.

IF (and ONLY IF) this IS a split DB with front-end and back-end files, you would have to adjust the links to the back-end file from the front-end. However, this would only have to be done once and saved. The way to do that is to open the DB and switch to the Database Tools ribbon to find External Data. Browse around in there to find the tool to relink the tables. You can select via check-boxes all the tables to be relinked in a single action, so it is easy-peasy.
yes it is split form. i dont understand what are front-end and back-end files can you explain please. also there are no tables. there is only one table. query is made based on the table and split form based on the query.
 
Not talking about split forms. That is something that gives you two views of the same data.

When your DB is NOT being used, how many files are involved? One or two? When you talk about moving the DB from a USB stick to a hard drive, how many files will you move for the DB? (NOT talking about how many PDF files you would move. That's data for the DB, not instructions or infrastructure.) I'm talking about files that are an intrinsic part of the DB even when it is NOT working.

This is something that you would have remembered splitting because you have to go through a Database Tools sequence to execute the split. A split form is a different animal.

If you have no tables, you can't have a back-end because the splitter would only initially move tables into a back-end. For what you describe, it would have nothing to move.

You asked what those are, so: The Front-end/Back-end (FE/BE) split is a way for multiple people to share a DB efficiently. You move all of the tables (i.e. the heart of the DB) into the BE file, which you then put in a folder visible to all of its users across a local area network. Everybody gets a private COPY of the main FE file that contains the forms, reports, queries, macros, and modules that are the active parts of the DB. The tables are passive in that context. Doing it this way limits file locking issues and Access can use the FE/BE split situation to have a bunch of users hitting the BE file at once, co-existing peacefully. There is more to it than that, but the takeaway is that your users share tables because they are passive, but everything else that is active gets distributed to the users.

I'm thinking you don't have a split DB, which means you have a single-file DB (which we might call "monolithic"). Check my previous comments on that point. Sorry if my answer confused you, but I was trying to decide what you were really using.
 
Not talking about split forms. That is something that gives you two views of the same data.

When your DB is NOT being used, how many files are involved? One or two? When you talk about moving the DB from a USB stick to a hard drive, how many files will you move for the DB? (NOT talking about how many PDF files you would move. That's data for the DB, not instructions or infrastructure.) I'm talking about files that are an intrinsic part of the DB even when it is NOT working.

This is something that you would have remembered splitting because you have to go through a Database Tools sequence to execute the split. A split form is a different animal.

If you have no tables, you can't have a back-end because the splitter would only initially move tables into a back-end. For what you describe, it would have nothing to move.

You asked what those are, so: The Front-end/Back-end (FE/BE) split is a way for multiple people to share a DB efficiently. You move all of the tables (i.e. the heart of the DB) into the BE file, which you then put in a folder visible to all of its users across a local area network. Everybody gets a private COPY of the main FE file that contains the forms, reports, queries, macros, and modules that are the active parts of the DB. The tables are passive in that context. Doing it this way limits file locking issues and Access can use the FE/BE split situation to have a bunch of users hitting the BE file at once, co-existing peacefully. There is more to it than that, but the takeaway is that your users share tables because they are passive, but everything else that is active gets distributed to the users.

I'm thinking you don't have a split DB, which means you have a single-file DB (which we might call "monolithic"). Check my previous comments on that point. Sorry if my answer confused you, but I was trying to decide what you were really using.
you are right I am the only one using the database. tool you mentioned will not work for me. question was if I move database file and pdf files will i loose links again (I believe i would) and if so can I prevent it or what to do.
 
Are your PDFs saved in child directories under the directory your application is in?
Are you planning to copy over the PDF files when you move your database?
 
Are your PDFs saved in child directories under the directory your application is in?
Are you planning to copy over the PDF files when you move your database?
Are your PDFs saved in child directories under the directory your application is in?
Are you planning to copy over the PDF files when you move your database?
aplication is in the main folder and pdf files are in subfolders. I intend to copy aplication and pdf files also. just copy everything.
 
Last edited:
aplication is in the main folder and pdf files are in subfolders. I intend to copy aplication and pdf files also. just copy everything.
actually i tried it and works. links are ok. but still if folder is changed links wont work. what should be done in such case.
 
I presume now that you mean that the hyperlinks won't work. Your original question and some of the earlier answers were about this exact problem. If the hyperlinks to the files (after migration) won't work, you need to update those links.

I'm trying to decide if there is a predictable pattern to this move so that you could just run an update query. But that might not be quite so easy if the migration pattern wasn't carefully followed.

According to post #19, your DB is working correctly. So are you planning to move the PDF files again? Or did you just move the DB and not the PDF files, so that the hyperlinks still point to the original location? I am still somewhat confused regarding your intention here.
 

Users who are viewing this thread

Back
Top Bottom