Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
General Field
Message
De
31/10/2002 07:39:42
Hilmar Zonneveld
Independent Consultant
Cochabamba, Bolivie
 
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Titre:
Divers
Thread ID:
00717066
Message ID:
00717265
Vues:
21
>>Once you put a file into a General field, it is difficult to take it out again.
>
>I do not agree here with you. For files that have appropriate OLE Server applications (like MS Word or Excel), you can downoad General field into OLEBoundControl and access all PEMs of MS Word application and document through it. This way you can just call MS Word's method to save document into the file on disk and that's all work you need to do to extract the file from general field in this case. For BMP files, for example, you could not do this because MS Paiont is not a real OLE Server application.

OK, I was thinking about images here.

>>Also, it takes up more space. Also, you can quickly approach the 2 GB file limit in VFP.
>>
>
>Thats also not true. File stored in General field in "internal" format that differs from file type to type and dependent on the OLE Server used to handle that file type. I know you have bad experience with JPEG images, but this is only very particular example and it does not apply in general. For example, take large, unencrypted and uncomplessed BMP file into general field. the size it takes on disk is only very slightly different from size in General field. JPEG files are complessed, but stored NOT compressed in Generalf ield, that is why you experienced large size increase. For MS Word documents, they do not take much more space compare to disk space, really.

Still, storing lots of files directly in the database might approach the 2 GB limit - whereas storing the files separately, the individual files will not give this size problem. Although the total space may be similar, according to your comments.

>General fields give a lot of very noice capabilities, though they very dependent on the client's machine software, so they should be avoided for anotehr reason - software compatibility. Just memo fiel size increase is not a big issue here.

I see.

>>Perhaps you might consider the alternative of storing only the filename in a character or memo field.
>>
>
>I agree with this - this option is the best one. Take care also to use NOCPTRANS option for such memo field, or use "memo (binary)" field type when creating it in the table.

>I think you can just extract documents into temporary disk file, scan them, then delete them if they're ok or update them if some of them were infected and fixed.

The original poster wanted to know the command-line arguments to do this automatically. This is precisely the part where I couldn't help.

Hilmar.
Difference in opinions hath cost many millions of lives: for instance, whether flesh be bread, or bread be flesh; whether whistling be a vice or a virtue; whether it be better to kiss a post, or throw it into the fire... (from Gulliver's Travels)
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform