Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
saving graphic images in dbt ? 1
- Thread starter tioconejo
- Start date
You need to use a RDD that can support binary data for the Memo files, and DBFNTX sure can't do that properly. Transcoding to BASE64 could help, but the hopelessly in-efficient storage of these .dbt memo's is going to spoil your day very soon :-(
I've used DBFCDX to store lightly encoded text in memo's (.fpt) but haven't got any experience with storing graphic files this way. Pretty sure FlexFile or Commix could handle this, but that should be investigated.
HTH
TonHu
I've used DBFCDX to store lightly encoded text in memo's (.fpt) but haven't got any experience with storing graphic files this way. Pretty sure FlexFile or Commix could handle this, but that should be investigated.
HTH
TonHu
The new Clipper 5.3 manual describes the use of BLOB files and the FlexFile drivers needed for storage of large graphic files. Unfortunately, I have been unable to get it to work well enough to call it dependable, and therefore cannot recommend it.
Best Regards,
David Tracy
Best Regards,
David Tracy
JockMullin
MIS
If you find a way compatible with clipper 5.x I would like to know also.
What I have done in my apps is put the graphics files in a folder and put the filename in the .dbf. Also I attrib the file to read-only shared so it can be concurrently accessed by multiple users without causing a sharing violation.
It works but it is a kludge because it requires a cleanup utility to remove files no longer referenced in the .dbf and a means of handling duplicate filenames.
Jock
What I have done in my apps is put the graphics files in a folder and put the filename in the .dbf. Also I attrib the file to read-only shared so it can be concurrently accessed by multiple users without causing a sharing violation.
It works but it is a kludge because it requires a cleanup utility to remove files no longer referenced in the .dbf and a means of handling duplicate filenames.
Jock
-
1
- #6
I have been using Flexfile in my applications since 1988 in both Summer '87 and in 5.2e, and currently have clients that are storing not only text in its natural form, but also scanned images. I have a client that has over 6.5 Gb of stored text and images that are accessed with no problems. This is a medical application that stores patient images for ID as well as chart notes, lab results and a multitude of data. There are also encrypion functions that are necessary of patient security with the advent of the current HIPA guidelines in effect. I have never tried using the BLOB functions in 5.3a or 5.3b as I can accomplish everything I need using Flexfile and a seaprate LLIBS library, portions of which were later bundled into 5.3. Flexfile is the way to go!
- Thread starter
- #7
A character field with a width of 6 char is created in the control database. Then using a series of v_retrieve and v_replace Flexfile functions, your data, whether it is text from a memoedit or a scanned or created image, is stored in a .DBV file that is separate from the control .DBF. You can create a multitude of .DBV files and associated character fields in your control .DBF and v_select the appropriate .DBV file.
The data is stored in the .DBV file similar to the way a file is stored on a hard disk, not not at all the way data is stored in a .DBT file where fixed blocks are used creating lots of wasted space. When a set of data is v_replace is issued, the data is stored in the .DBV file in the first available location in the file. If the data is v_retrieved and its length in changed, it will be v_replaced in to the firat available location and the previous storage location is then made available for use by any following request for storage that will fit in that space. An analysis of unused space in a .DBT file is usually no more that 8-10%. The text data can be encrypted as it is stored, although there is no connection to the data and the.DBF record it is associated with. I have found no limit tot he size of an image that can be stored in my usage of .DBV files and text storage will be restricted by the way the data will be displayed or edited with in the Clipper program.
Hope this helps explain it to you.
I am open to future questions regarding this subject.
Sam Boomer
sdb_tech at mindspring dot com
The data is stored in the .DBV file similar to the way a file is stored on a hard disk, not not at all the way data is stored in a .DBT file where fixed blocks are used creating lots of wasted space. When a set of data is v_replace is issued, the data is stored in the .DBV file in the first available location in the file. If the data is v_retrieved and its length in changed, it will be v_replaced in to the firat available location and the previous storage location is then made available for use by any following request for storage that will fit in that space. An analysis of unused space in a .DBT file is usually no more that 8-10%. The text data can be encrypted as it is stored, although there is no connection to the data and the.DBF record it is associated with. I have found no limit tot he size of an image that can be stored in my usage of .DBV files and text storage will be restricted by the way the data will be displayed or edited with in the Clipper program.
Hope this helps explain it to you.
I am open to future questions regarding this subject.
Sam Boomer
sdb_tech at mindspring dot com
- Status
Similar threads
- Locked
- Question
- Locked
- Helpful tip
- Locked
- Question
