Relative path vs. absolute path possible in storing pictures?

  • Thread starter StargateFanFromWork
  • Start date
S

StargateFanFromWork

Every db I've made up till now in FMP has had few pix so I've just stored
them in the db itself. Now FMP frowns on this as much as A2K you
understand! <grin> But there were so few pictures, it didn't hurt.

The current A2K db I'm creating will have potentially a picture for each
record so it will be necessary this time around to just reference each. I
have a problem with absolute paths, however. When one decides to re-locate
a db, the pictures would no longer work if absolutes are used. Can we use
relative ones in A2K even when choosing the picture? I found an example db
that does this while explaining the procedure and after pressing the button
and choosing the graphic, the picture appears in a large box, while a
rectangular box underneath displays the complete path. Here are the
instructions from that example db:

"
It is usually preferable NOT to store OLE objects like pictures in the table
itself. It causes massive database bloat. The usual solution is to store
the pictures as files on the hard drive and store the file name in the
table. This sample demonstrates how to use the OpenSaveFile API to find the
picture file you want loaded into the database.

By default, it starts looking in the same directory as where the application
resides. If you want to change that, change this line:
pathname = CurrentProject.Path
to the path you want:
pathname = "C:\My Documents"
"

If I have a folder on the desktop called, say, "Movie Database" that has an
A2K file called "My Movie Database.mdb" and a folder called "images" for the
pictures, can A2K be made to just reference only the images folder along
with the graphics so that behind the scenes we'd just get something like
this: "images\graphic01.jpg" instead of this: "c:\desktop\Movie
Database\images\graphic01.jpg" which wouldn't work once we moved the mdg
files and images to, say, somewhere my D drive?

Thanks so much. :eek:D
 
J

jacksonmacd

Store the name of some "root" folder in a single record in an
"administrative" table of your database. Store the pathname relative
to this root in the each picture's individual record in a different
table. When it comes time to retrieve the picture, concatenate the two
parts to make a full pathname. You could do this with VBA code or with
a query, depending on the structure of your program.




Every db I've made up till now in FMP has had few pix so I've just stored
them in the db itself. Now FMP frowns on this as much as A2K you
understand! <grin> But there were so few pictures, it didn't hurt.

The current A2K db I'm creating will have potentially a picture for each
record so it will be necessary this time around to just reference each. I
have a problem with absolute paths, however. When one decides to re-locate
a db, the pictures would no longer work if absolutes are used. Can we use
relative ones in A2K even when choosing the picture? I found an example db
that does this while explaining the procedure and after pressing the button
and choosing the graphic, the picture appears in a large box, while a
rectangular box underneath displays the complete path. Here are the
instructions from that example db:

"
It is usually preferable NOT to store OLE objects like pictures in the table
itself. It causes massive database bloat. The usual solution is to store
the pictures as files on the hard drive and store the file name in the
table. This sample demonstrates how to use the OpenSaveFile API to find the
picture file you want loaded into the database.

By default, it starts looking in the same directory as where the application
resides. If you want to change that, change this line:
pathname = CurrentProject.Path
to the path you want:
pathname = "C:\My Documents"
"

If I have a folder on the desktop called, say, "Movie Database" that has an
A2K file called "My Movie Database.mdb" and a folder called "images" for the
pictures, can A2K be made to just reference only the images folder along
with the graphics so that behind the scenes we'd just get something like
this: "images\graphic01.jpg" instead of this: "c:\desktop\Movie
Database\images\graphic01.jpg" which wouldn't work once we moved the mdg
files and images to, say, somewhere my D drive?

Thanks so much. :eek:D

**********************
(e-mail address removed)
remove uppercase letters for true email
http://www.geocities.com/jacksonmacd/ for info on MS Access security
 
S

StargateFan

Store the name of some "root" folder in a single record in an
"administrative" table of your database. Store the pathname relative
to this root in the each picture's individual record in a different
table. When it comes time to retrieve the picture, concatenate the two
parts to make a full pathname. You could do this with VBA code or with
a query, depending on the structure of your program.

Oh. Well, I guess I can't do what I initially hoped to do <g>. I
didn't really understand all of that (lord, it's tough being a rank
newbie again! <g>). I'll keep this information, though, for when I
know more and can try to figure out how to do what you say. Good to
know that however difficult, there may be a workaround.

All I know is that absolute path are absolutely always a pain in the
butt for me. I often will finetune a folder name for a while until
it's just right and anything that works on absolute paths is always a
pain while that is happening. Then I also like to have working paths
for things I end up transferring to CD. Or how about once I take from
my C drive to the D drive? <sigh> Not good.

I'm definitely going to hold off putting pictures in, that's for sure!
<lol>

Thanks.
 
B

Bob

You can certainly use relative paths. As mentioned in your quote, 'CurrentProject.Path' returns the path
to the access mdb itself. Therefore, if you store the images in a subdirectory, for example 'images',
you can simply concatenate CurrentProject.Path, 'images' and the filename (which you presumably have stored
in a table). Then, wherever you move the database, or however you access it (via UNC or share, for example),
the paths will work (provided the images are moved with the database). Note that currenproject.path works
in Access 2000 and later - if you need to support Access 97, use 'CurrentDb.Name' and parse the path out
of it.
 
L

LW via AccessMonster.com

Bob, what if you want your images to be stored in a folder underneath the
folder where the backend database resides? CurrentProject.Path and CurrentDb.
Name, I presume give you the path to the frontend database, which may reside
on the user's local machine. Is there any way you can access the value of the
path to the linked tables?

LW

You can certainly use relative paths. As mentioned in your quote, 'CurrentProject.Path' returns the path
to the access mdb itself. Therefore, if you store the images in a subdirectory, for example 'images',
you can simply concatenate CurrentProject.Path, 'images' and the filename (which you presumably have stored
in a table). Then, wherever you move the database, or however you access it (via UNC or share, for example),
the paths will work (provided the images are moved with the database). Note that currenproject.path works
in Access 2000 and later - if you need to support Access 97, use 'CurrentDb.Name' and parse the path out
of it.

--
_______________________________________________________
http://www.ammara.com/
Image Handling Components, Samples, Solutions and Info
DBPix 2.0: Add pictures to Access, Easily & Efficiently
Every db I've made up till now in FMP has had few pix so I've just stored
them in the db itself. Now FMP frowns on this as much as A2K you
[quoted text clipped - 33 lines]
Thanks so much. :eek:D
 
B

bob

You can get the path to the back-end where a particular linked table resides by using the following:

Mid(CurrentDb().TableDefs("NameOfLinkedTable").Connect, 11)

(thanks to Doug Steele & Allen Browne)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top