one 2 one link to table with Jpeg Image Field

[Vastor]

I’m trying to use a memo field and a jpeg image field in a desktop database I’m creating.
I want to have the memo field and image field in their own tables, with one to one links to the parent table.
I have tested this in a three table test database. I can get the memo table and field to work fine, However, I’ve had no joy with the jpeg image field table. The field doesn’t import the JPG and the link field doesn’t get filled with the parent link.
I’ve looked through the forum to see what I might be doing wrong and tried many ways to make this work. I’ve seen problems and recommendations to not use this field type, but didn’t see anything about this field type not working. I have tried the “image file reference” field type and it does work, but I would prefer to put the image in the database where it won’t get deleted or be moved. The database will only be about 100 records, so I don’t think there will be a problem with size.
I would appreciate any help finding out what I’m doing wrong.

I'm going to try to include the test database I've been trying to get to work, along with a couple of the JPGs

I’m on - Ver. 9 platinum edition build 2095 addins: build 3264


Vince

[Ted Giles]

V9 Platinum same build.

Please see attached, which may give you what you require.
I have created a new Set with the Pic at the top.
Changed the NameID to Numeric 4. This is beause it is better to use numerics if your application is going to be ported anywhere like an SQL environment. It is also more complex using Char as a linking filed.
Two types of pic shown on the test form.
1) where the pic is just a reference and
2) where it is embedded.

You need to click out of the box to display.

Both have merit, although some people advocate having the reference as there is no need to hold the pic twice.
If you have a formalised proto session at say every 5th year to keep access passes fresh, then if the same refernce is used, the pic should be current.

[Vastor]

Ted,
Thank You for your speedy reply.
Unfortunately Due to circumstances beyond my control, I will not be able to review the material for a few days.
Please bear with me.
Thanks again
Vince

[Vastor]

Ted,
Appreciate your help and interest.
Thanks for the examples of other methods. I’d prefer not using the “image file reference” field as it is to easy for clients to move and delete stuff. Also, embedded images make the database more portable.

Having the Picture table (Jpeg image field) as a parent table causes other issues, as there is always a Name entry, but may not be a Picture for the record. I also don’t want the client to change or enter the record id for the picture table, so it will have to be auto increment. I think if the picture id is auto increment I’ll end up with the same problem I have now.

I really believe there is a BUG associated with the “Jpeg Image” field type, being in a child table, in a ONE to ONE relationship, with the only other field being the link field. When this situation occurs, and a picture is imported, neither the link id from the parent record, nor the picture, end up in the record.

I’m sending a zipped database, in the simplest form I can, to prove this and would appreciate it if you would take the time to enter two or three records consisting of a name and a picture.

Then default browse the Picture table and verify that you too don’t have any records, link ids, or pictures in that table.

That would tell me it’s Alpha and not me, or my PC, and then I will stop trying to make it work and find another way to accomplish what I want to do.

Thanks a bunch
Vince

[Ted Giles]

Vince, not sure if this helps or not, but I have added 4 pictures using the Auto Increment, and one No Pics - name only.

Have a look at the [picture_01 set structure. Sets are created at runtime, so they can be any configuration you want them to be.
The test form works with that set.

I can confirm that if you put the picture table as a subbordinate in a set like you have been doing - it doesn't work.
However, with a bit of tweaking it can be made to work.

[Vastor]

Ted,
It seems that method gets the first record out of sync and you never have a name in the first record.
I could use It myself but can’t give it to a client.

If you take a fresh copy of the last database I sent you (make sure the tables have been cleared), go to the picture table and only change the field type of the picture field to any type in field (try memo, numeric, or character) and save it, the database will work the way it should.
The jepg image field will also work if there is an entry field in the same table before the jpeg image field (what’s that about).
I think the jpeg image field will work in a single field (plus link to parent and auto increment pictureID), one to many link, table.
No consistency on how you use this field type.
The use of a field shouldn’t be determined by the link type, that’s BS.

I think it is a broken field type that has never worked, as it should, and probably still doesn’t work in V11.

I’ve about given up on this one, it’s wasting too much of Your, and My, time.

I just won’t provide a contact picture or will embed the picture in the parent table amongst all the other crap they want, ugly thought.
Could also give them multiple pictures per contact, with a one to many link picture table.

Thanks a bunch for all your help
Vince

[Ted Giles]

Yes you are correct Vince.
Only thing I can suggest is that you create a separate table as you suggest.
I'll give a bit more time after the celebration weekend here in the UK, as there really must be a way around this, however if you populate the Names table first, then adding a Picture can be done the way you want to.

Edit. Had another fiddle.
It's not possible to add a picture using the Set.
If you look at the Alpha Sports example, Salespeople ID/Name and their photo are in one table.

Is there a reason you cannot do the same?

[Vastor]

Ted,

That's an excellent work around.
I always look to alpha sports for answers, but it didn't click this time.
I'll use the Name and picture as a parent table, other crap in a profile table as one to one, Memo field table one to one, etc., etc..
That should keep any one table from getting bloated, if the image file is kept small.
Wouldn't have a solution without you.

Thanks again for your help
Vince