Ben,
I tend to agree. At least in my situations, I have not seen the benefit of keeping many thousands of PDFs externally. A database is meant to store data, why not use it as such? I have worked with 3 commercial programs that are widely used throughout the country. They all have the standard option of re-printing a statement at will, for any given past set of parameters. I.E. customer, date, statement number, past due, aging etc, etc. None of these programs store statements in external PDF form as a means of history and retrieving historical records. Storing statement data in a table is easy and then you have the full power of Rbase to do what you want to with it. Create PDF's for emailing, spreadsheets, printing, combining, searching, sorting, etc. No need for external PDF mergers. You have full security over the data without dealing with non- rbase functions such as folder security access etc. (Imagine writing a statement program for a customer and then having to deal with thier network folder access as part of your program security) So I do not mean to say that the other options presented on the list are not good. Everyone has thier own situations and there is no "one size fits all", especially in programming! With that said, it will be informative to hear other's points of view on this. I can always learn! I simply tend to look at "what is the bang for the buck" as the phrase says. I find it much easier to control inside Rbase versus outside. -Bob ----- Original Message ----- From: "Ben Petersen" < benpetersen @ softcom .net> To: "RBASE-L Mailing List" < rbase -l@ rbase .com> Sent: Tuesday, March 23, 2010 8:00:36 AM GMT -06:00 US/Canada Central Subject: [RBASE-L] - Re: Printing a bunch of PDF files I've been following this thread with some interest as it flirts with some ideas I've been rolling around. What I'm wondering is what is the benefit of PDFs as opposed to the database approach someone else suggested? I'm thinking that a DB of duplicate/archival (AR) data is more secure and equally available as individual PDFs , assuming non-data things like signatures aren't being stored? Ben On Mon, Mar 22, 2010 at 3:13 PM, Emmitt Dove < emmitt [email protected]> wrote: > Karen, > > > > In our Invoicing Module, we store PDFs of every invoice created. A table > stores invoice number, filename , customer number, invoice date, batch > number, total dollars, etc. A form exists that lets the user hone in on an > invoice they wish to review by selecting customer, date range, or invoice > batch, or they can simply enter the invoice number if it is known. Once > they have located the invoice in question, the form displays the summary > information for the invoice. A button exists to launch the PDF to view the > original document. They can also print or email the document. > > > > We organize the PDFs by year and month. We also load the summary data and > the path to the PDF into a centralized database (we currently have three > invoicing locations) for use by Accounts Receivable. They have the same > lookup / reprint / email capabilities, even though the PDF may be stored on > any one of three servers on the WAN in other states. > > > > This all works quite nicely. All you need is a table to store the basic > information about the document, including the full path to the document, > document name, and sufficient identifying information to allow the user to > locate the document of interest. > > > > Forget about how many PDFs might be involved – that is a non-issue. Store > them in a structured fashion, as in by year and month. Maintain a table > with enough qualifying information to lead you to a distinct PDF , and > provide the user an interface to get them to the desired document. > > > > If you really are intimidated by the sheer number of documents, then also > write a routine to purge them by date. That task, also quite simple, is > another conversation. > > > > Emmitt Dove > > Manager, Converting Applications Development > > Evergreen Packaging, Inc. > > emmitt [email protected] > > (203) 214-5683 m > > (203) 643-8022 o > > (203) 643-8086 f > > emmitt [email protected] > > > > From: rbase -l@ rbase .com [mailto: rbase -l@ rbase .com] On Behalf Of > [email protected] > Sent: Monday, March 22, 2010 14:15 > To: RBASE-L Mailing List > Subject: [RBASE-L] - Re: Printing a bunch of PDF files > > > > Bob: An interesting thought... Yes, this could grow into thousands of > individual PDFs very quickly. So there would have to be some maintenance to > throw older ones out (luckily they run just once a month, so only 12 > "batches" worth a year). I'd have to think about how I could save the data > in a table so that it can be recreated at any time... That would be a > boatload of programming. > > I like Sami's idea of one indexed PDF file, but if they wanted to email just > one page they would have to have the full version of Acrobat to extract a > page to another filename , or I'm assuming R:PDFMerge would let them extract > a page to a file. > > Karen > > > > I use this method in the initial creation of all statements. Have an end of > month job > > run and create all statements. Then the statements can be printed from this > table along with > > a print and send status. You have a lot of print options. You can change > order by or select by > > for different groupings. Such as some customers get emailed direct, others > get hard copy and > > others both. > > > > As always, many ways to accomplish an end task. > > > > -Bob > >
