It depends, IMHO, on how many documents. If you are keeping large numbers of images, as one of our clients does, we prefer to keep separate files and point from within R:Base to keep the database sizes manageable.
MJS <[EMAIL PROTECTED]> wrote: >Awesome......just one question (at the moment). Is there any >advantage/disadvantage to storing the documents on a harddrive with unique names, >and perhaps unique subdirectories (rather than as varbit values in a table), and >use Rbase to track where they are, and let Rbase launch the app to view them? I >suppose it should work either way, but I would rather know if you tried it both >ways and why you picked your method. > >Thanks a million! > >Mike Sinclair > >Troy Sosamon wrote: > >> Mike, >> >> All the code I used for the demo is on the developers conference CD along with >> the power point presentation. >> >> Here is how I do it. >> >> 1. You have to use whatever method works for you and get your document into a >> file. We use inexpensive HP scanners with doecument feeders on them. We set >> them to default to store the pages in files at 200 dpi jpg files named >> temp.jpg. The HP software then automatically numbers multiple pages test.jpt, >> test2.jpg, test3.jpg... >> >> 2. I have a program in R:base that will read the files and load them into the >> database. >> >> 3. Storing the files in R:base. I use 3 tables: >> docs, docs_doc, and docs_loc. >> The docs table holds an autonumbered id called docid int, scan_date date, >> file_type text 3, doc_loc text 8, last_access date, and other information >> linking that record to the appropriate record in the database. >> The docs_doc table has 2 columns called docid and doc_image of type varbit. >> This is where the actual image lives. >> The docs_loc table is used to keep track of the locations of the databases >> that store the documents after you move them from your primary database. >> >> The problem with storing images in your database is your #4 file gets too >> large, so I create other database and move the records from the docs_doc table >> to other database. I keep track of what database each document is in in the >> docs table, and I keep track of where the database is in the docs_loc table >> >> ok, so you scan your document to files c:\temp.jpg, c:\temp2.jpg, temp3.jpg. >> You select the client (or whatever) record in your database this document >> relates to. You run a program that reads the files, load the docs table >> getting a docid, links to your client record, and then load the image into >> docs_doc, and you delete your temp jpg files after you load them. >> >> Now you have 4 records in the docs table and 4 records in the docs_doc table. >> >> To look at your document, you pull up your client and do a choose command on >> the docs table for that client. You get the docid, file_type, and >> doc_location from the docs table. You look in the docs_doc table to see if >> your blob is there. If it is, you dump it out to some file say >> c:\temp$$$.jpg. Next you either zip out of R:base or use launch and use >> whatever graphic viewer you want to look at the thing. (You keep track of the >> file extension so you can programatically decide what viewer you want to use. >> You can store any file you want in R:base. I store jpg, pdf, and doc files >> just to name a few.) If your document is not in the docs_doc table, you use >> the doc_location field, look that up in the doc_loc table, connect to that >> database, dump the blob to a file, load the file into your main database, and >> then follow the procedure above. >> >> I load the record back into the main database, because of the way we do >> business. Usually when someone needs an old file, they may use it 10 times in >> a week and then not use it for a couple of years. >> >> When the #4 file gets over 400 megs, I start moving records out of the >> docs_doc table and load them into secondary databases. I update the docs >> table with the name of the DB that the record is loaded into. The docs_loc >> table has 1 record for that database with it's location. >> Once a document is moved to a secondary database, it is never deleted from it. >> I also burn the secondary databases onto CDs to keep off site. You can move >> those secondary database around or even take them off line, and you just need >> to modify the 1 record in the docs_loc table. I don't let the secondary >> database get over 600 megs so they will fit on CDs. If I ever need to, I >> could get a CD jukebox and access them from there. I have not needed that >> because I have a server with big drive array, and I figure I won't need to >> worry about storage for a couple of years. >> >> This whole procedure is very simple. I control everything with 3 short >> command files. One files reads in the jpg files and loads them into the >> database. The second file pulls the files out of the database and starts the >> viewer, and the third file is used to move files from the production databse >> to the secondary databases. I think I have about 15 secondary databases >> storing around 75,000 documents. >> >> This method works great. I don't think I would use it if I were going to scan >> 100,000 pages a month, but it would still work if you did. If you were going >> scan large numbers of documents, you would want to get a better storage format >> to get the images smaller, but R:base would still work to store everything. >> >> Troy Sosamon >> Denver, Co. >> >> >===== Original Message From [EMAIL PROTECTED] ===== >> >Hi all, and esp Troy, >> > >> >Do you have an outline on how you do the "TROY METHOD" of document storage? >> It >> >seemed to work so well at the developers conference.....I just didn't want to >> >reinvent that wheel! >> > >> >Mike Sinclair >> > >> >================================================ >> >TO SEE MESSAGE POSTING GUIDELINES: >> >Send a plain text email to [EMAIL PROTECTED] >> >In the message body, put just two words: INTRO rbase-l >> >================================================ >> >TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] >> >In the message body, put just two words: UNSUBSCRIBE rbase-l >> >================================================ >> >TO SEARCH ARCHIVES: >> >http://www.mail-archive.com/rbase-l%40sonetmail.com/ >> >> Troy Sosamon >> Denver Co >> [EMAIL PROTECTED] >> >> ================================================ >> TO SEE MESSAGE POSTING GUIDELINES: >> Send a plain text email to [EMAIL PROTECTED] >> In the message body, put just two words: INTRO rbase-l >> ================================================ >> TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] >> In the message body, put just two words: UNSUBSCRIBE rbase-l >> ================================================ >> TO SEARCH ARCHIVES: >> http://www.mail-archive.com/rbase-l%40sonetmail.com/ > >================================================ >TO SEE MESSAGE POSTING GUIDELINES: >Send a plain text email to [EMAIL PROTECTED] >In the message body, put just two words: INTRO rbase-l >================================================ >TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] >In the message body, put just two words: UNSUBSCRIBE rbase-l >================================================ >TO SEARCH ARCHIVES: >http://www.mail-archive.com/rbase-l%40sonetmail.com/ > -- __________________________________________________________________ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ ================================================ TO SEE MESSAGE POSTING GUIDELINES: Send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: INTRO rbase-l ================================================ TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: UNSUBSCRIBE rbase-l ================================================ TO SEARCH ARCHIVES: http://www.mail-archive.com/rbase-l%40sonetmail.com/
