Alexander
The code works great. I've even ported it over to the build_detail in nph-build.cgi and site_html_print_cat in HTML_templates.pm and with the minor change of changing the $rec-> to the appropriate $variable-> I've gotten everything to work.
As far as the slow down, I probably can't really speak to that as of yet. Right now, I can only go by feel and it's telling me that it's a tiny bit slower, but not much. I get the sense that the slowdown is from having to open the db.
Later next week once I get my database loaded with actual data I'll get a better sense of that.
If I find that there is indeed a major sacrifice in performance, I'm thinking to look for a way to add an attachment drop down field to the links and category databases. Then when an attachment gets added to the attach db, it should update the info in the Links db attachment field. Probably very tricky.
One final comment on this. IN DBSQL attach_file - The default installation causes an uploaded attachment to be named ID.fil regardless of what it the attachment is. I found that a new upload would overright the old upload file (this is important if you only want to allow one attachment per Link), yet the attach database record would indicate there were two attachments(I think that's a bug, because you'd delete one attachment thinking the other was still there, but it wasn't because both attachments accessed the same file (i.e. ID.fil) Anyway, I made the following change in DBSQL.pm
sub attach_file {
change:
$fn = $fh;
to:
$fn = $data_id . $fh ;
That simply adds the the actual filename to the ID number, and allows for multiple attachments.
Then change:
VALUES (?, $data_id, "$data_id.fil", $fn, $ft, $size)
to:
VALUES (?, $data_id, $fn, $fn, $ft, $size)
I haven't figured out why both a file name AND a server name were needed nor why the server wanted to call it .fil. I'm still confused on that. And also trying to view an image called 15.fil just gave me a bunch of strange characters. (The browser would load it fine, but I couldn't "view image" from Netscape 4.6
Anyway, because the ID is now added to the filename itself, the following advantages can be spoken of:
1. All distinct records can still have the same named file uploaded to them. Note: You can't upload a file called picture.jpg twice and expect two version to be available to the same ID.
2. Any record can have any number of attachments uploaded (assuming of course the uploaded file is a unique name.)
I haven't tested this out from modify.cgi, or add.cgi yet. I'm assuming that because they use the same sub routine that it will be fine. Anyway. If I run into trouble on that I'll be sure to share it.
Alexander, Thank you again for all your help.
Peace.
Kyle
The code works great. I've even ported it over to the build_detail in nph-build.cgi and site_html_print_cat in HTML_templates.pm and with the minor change of changing the $rec-> to the appropriate $variable-> I've gotten everything to work.
As far as the slow down, I probably can't really speak to that as of yet. Right now, I can only go by feel and it's telling me that it's a tiny bit slower, but not much. I get the sense that the slowdown is from having to open the db.
Later next week once I get my database loaded with actual data I'll get a better sense of that.
If I find that there is indeed a major sacrifice in performance, I'm thinking to look for a way to add an attachment drop down field to the links and category databases. Then when an attachment gets added to the attach db, it should update the info in the Links db attachment field. Probably very tricky.
One final comment on this. IN DBSQL attach_file - The default installation causes an uploaded attachment to be named ID.fil regardless of what it the attachment is. I found that a new upload would overright the old upload file (this is important if you only want to allow one attachment per Link), yet the attach database record would indicate there were two attachments(I think that's a bug, because you'd delete one attachment thinking the other was still there, but it wasn't because both attachments accessed the same file (i.e. ID.fil) Anyway, I made the following change in DBSQL.pm
sub attach_file {
change:
$fn = $fh;
to:
$fn = $data_id . $fh ;
That simply adds the the actual filename to the ID number, and allows for multiple attachments.
Then change:
VALUES (?, $data_id, "$data_id.fil", $fn, $ft, $size)
to:
VALUES (?, $data_id, $fn, $fn, $ft, $size)
I haven't figured out why both a file name AND a server name were needed nor why the server wanted to call it .fil. I'm still confused on that. And also trying to view an image called 15.fil just gave me a bunch of strange characters. (The browser would load it fine, but I couldn't "view image" from Netscape 4.6
Anyway, because the ID is now added to the filename itself, the following advantages can be spoken of:
1. All distinct records can still have the same named file uploaded to them. Note: You can't upload a file called picture.jpg twice and expect two version to be available to the same ID.
2. Any record can have any number of attachments uploaded (assuming of course the uploaded file is a unique name.)
I haven't tested this out from modify.cgi, or add.cgi yet. I'm assuming that because they use the same sub routine that it will be fine. Anyway. If I run into trouble on that I'll be sure to share it.
Alexander, Thank you again for all your help.
Peace.
Kyle
