Jump to content
Salesforce and other SMB Solutions are coming soon. ×

Looking for Sage Advice on Container Fields


The Digital Man
 Share

Recommended Posts

Back when I first started working with FileMaker Pro (Version 5.5) it was advised to store "REFERENCE ONLY" to the container object rather than load the object into the database. This was because each table could only be 2 GIG in size. Beyond that you ran into trouble or so I was told.

 

Does this advice still hold true?

 

I'm inclined to store the object inside the database so I don't have to worry about "links" getting broken. But I am open to advice on this.

 

If I store it as a REFERENCE ONLY how do I capture the "PATH & FILENAME" they choose? I used to use the Troi plugin for this but would like to avoid the plug in if possible on this project.

 

Thanks in advance as always.

Link to comment
Share on other sites

So is the general consensus to still reference only rather than embed the container field documents?

 

Does anyone know what the size limits are on the database file now?

 

Thanks

Link to comment
Share on other sites

FileMaker Knowledge Base: ID 5400

 

Technical Specifications - FileMaker Pro 8 and FileMaker Pro 8 Advanced

 

Question

 

What are the Technical Specifications of FileMaker Pro 8?

 

 

Answer

 

APPLICABLE TO

FileMaker Pro 8

FileMaker Pro 8 Advanced

 

File size: Limited only by disk space, to a maximum of 8 TB (terabytes) on a hard disk and OS API capability.

 

Number of files per disk: Limited only by disk space.

 

Number of files open simultaneously: Up to 125 files recommended.

 

Number of remote users per file: Maximum of 5 concurrent client.

 

Number of files shared: There is no limit.

 

Number of sessions via Web browser: Access to web-published database is limited to 5 concurrent sessions. Note. If another view is opened through 'New Window' that's still in the same session.

 

Number of tables per file: 1 million.

 

Number of records per table: 64 quadrillion total records over life time of file.

 

Maximum record size: Limited by disk space or maximum file size.

 

Number of fields/columns per record: 256 million total fields over life time of file.

 

Number of relationships per file: Limited only by disk space or maximum file size.

 

Length of field name: Up to 100 characters.

 

Field types: Text, Number, Date, Time, Timestamp, Container (for OLE objects, sound, picture, movie, documents, including Microsoft Word or Excel files, Adobe Acrobat PDF files, PowerPoint presentation files and so on) and Summary. The Global type is specified as an option.

 

Serial number options: The maximum number is limited by the Number type's range. In the Auto-Enter Serial Number option, user can enter up to 255 characters in the 'next value' edit control and numbers in the range 1 to 32767 in the 'increment by' edit control. If alpha numeric the rightmost characters that are numbers are incremented.

 

Maximum field size, by type:

 

Text: Up to 1 billion characters per field per repetition (limited by available memory) with optional text style runs and paragraph runs. Index is based on the first 100 characters of each word or value.

Number: Support values from 10^-400 up to 10^400 and the negative values of the same range. Index based on the first 400 significant digits. Up to 1 billion characters per field. The first 400 digits are indexed.

Date: Gregorian calendar with the range of 1/1/0001...12/31/3000. Month, day, year order based on system settings when file is created.

Time: Input formats: Hour:Minute:Seconds.Fractional, Hour:Minute:Seconds,Minute:Seconds.Fractional, Hour:Minute, Seconds.Fractional and Seconds. Time may be preceded by a negative sign and each numeric value must be in a range of 0 to 999999. Times are not limited to 24-hour format to allow for calculations spanning multiple days. If the minutes or seconds exceed 60, the excess is carried over to minutes or hours as appropriate.

Timestamp: Standard date followed by spaces and then by a time in the range of 0:0:0.0 to 23:59:59.999999.

Container: Multiple streams of binary data totaling no more then 4 gigabytes.

Calculation: Depends on result type.

Summary: Depends on result type.

Number of field repetitions (sub records): Up to 32,767 for each field.

 

Indexed (key) fields per file: Any field may be specified to index as an option, except: Container, Summary, Global, or unstored Calculation fields.

 

Number of sort levels: No limit.

 

Size of calculation formula: Maximum of 30,000 characters, including text and numbers, any referenced fields, operators, functions and parentheses.

 

Calculation operators: =,, >, =,

 

Number of calculation functions: 266.

Aggregate 9

Date 13

Design 20

Errors 1

External 3

Financial 4

Get 86

Logical 15

Miscellaneous 5

Number 18

Operator 22

Path 5

Repeating 3

Summary 1

Text 41

Text Formatting 8

Time 4

Timestamp 1

Trigonometric 7

 

Number of summary functions: 12

 

Number of layouts per file: Limited by disk space or maximum file size.

 

Layout size: Up to 110 inches wide by 110 inches long; may be limited by currently selected printer and page setup. Objects beyond current page width do not print.

 

Number of layout objects: Maximum of 32,768 objects on each layout.

 

Number of scripts: Limited by disk space. Displayed in Scripts menu: 512 on Windows, 32,767 on Mac OS.

 

Number of columns across the page: Up to 99 columns.

 

Number of labels across the page: Up to 99 labels.

 

File formats for import: FileMaker Pro, Tab-Separated Text, Comma-Separated Text, SYLK, Excel, ODBC, DBF (dBASE), DIF, WK1, WKS, BASIC, Merge

 

File formats for export: Tab-Separated Text, Comma-Separated Text, SYLK, DBF (dBASE ), DIF, HTML, WK1, WKS, BASIC, Merge, XML, FileMaker Pro

 

Picture formats for import: JPEG, GIF, PNG, BMP, Metafile (Windows only), Enhanced Metafile (Windows only), EPSF, PICT, TIFF, JFIF, JPEG 2000 (Mac OS X only), PDF (Mac OS X only), QuickTime movies and other formats supported by QuickTime (PSD, FlashPix, QIF, SGI, TGA, MacPaint).

 

Limit of Repetitions for Variables in an Iterative loop:10^400 for the variables if they are defined as numbers

 

Recursion limit for custom function:

 

50,000 recursive calls total

The call stack is only allowed to be 10,000 calls deep at any point.

If these limits are violated, the custom function will return "?".

Note that tail-recursion is properly optimized, so tail calls do not increase the size of the call stack.

Link to comment
Share on other sites

Thanks Pete,

 

The information you provided is quite impressive and interesting. I noticed it mentioned CONTAINER FIELD DATA could only be up to 4 GIG in a file. So even though the file can be in size up to 8 terrabytes it's only going to allow me 4 GIG in CONTAINER field data. Thats only double from what it was in 6.

 

I guess you've answered my question. I should probably plan on referencing only the image data.

 

I guess I could create a seperate file for the sole purpose of holding data in a container field and relate that file to my main solution file. Create a new one for each year and have the year be a function of the relationship so it looks in the right year file for the image. I probably wouldn't exceed 4 GIG in one year. But that doesn't strike me as being a very elegant solution and sure as I code it that way we'll have a busy year and exceed the 4 gig.

 

Thanks again everyone!

 

I shall proceed carefully and hopefully in the end it will all come out just fine.

Link to comment
Share on other sites

Regarding the "Multiple streams of binary data totaling no more then 4 gigabytes," I'm pretty certain that is per container field, as explained to me by a FMI Team Leader when FM7 was released. That "totaling" qualifier applies to the stream. For example, static images may be limited to 2gig, while movies have a limit of 4gig. (Static v. movie isn't the most accurate way to characterize this, but hey, there are too many streams to run down ... search "Working with data in container fields" in your FMHelp.) Then, the 8TB limit is imposed on the file.

 

First and with respect to any graphic sources for your GUI, you'll have fewer headaches if those images are inserted for ease of use throughout your solution.

 

But from what I gather, you're contemplating a "library" for perhaps tons of images. There's at least two branches of consideration here, but both involve your estimate of the total weight of images over the life of your solution.

 

(1) If your heart is set on a Single-File solution, you may be best served in the long run to employ file references. However, this comes with the "broken links" scenario you mentioned. Day-to-day operations may be just fine, but if you want to take the show on the road, your solution will be somewhat hobbled if the directories for those image files aren't transferred, as well. (As for system backups, the image directories/files will be part of your archiving regime.) You know all this already, but I mention it here for those keeping score at home.

 

(2) If you're wanting all images to reside in FM, it's back to the weight issue. One option is to "thumbnail" your images, then insert these light-weight renderings into containers. Your Image records could even include a second field for file-paths to the true image ... or a second container field storing only the file reference ... a "blending" of the two approaches, if you will. Otherwise, many developers are advocating a separate file for Images in this instance because (a) it helps you stay under the 8TB limit of your main file, (b) backups can be done piece-meal if your Images file changes infrequently, and © when hitting the road, you at least have the option to leave the Images file back at the mother ship (although, this is where "thumbnailing" would really pay off).

 

Okay, coffee's ready ... gotta go!

Link to comment
Share on other sites

Thanks One Guy!

 

You have clarifed things immensely and now I am really leaning toward embedding the images simply to avoid the "broken links" issue.

 

The container fields appear in several places in my solution but the bulk of them are in just 3 (err 6) tables. And the beauty of it is that at the moment the solution is engineered to conveniently move 3 of those 6 outside of the main file.

 

I have a JOB table which contains 1 container field to hold an actual scan of the P.O. (This may be overkill since we also have a text field for the P.O. number but my boss REALLY likes being able to INSTANTLY view any given P.O. while he's browsing the job records.) So that feature is for him and makes him happy which keeps my pay check being signed. lol.

 

I have a COMPONENTS table which is a one to many relationship from the job table. Each component record has two container fields so that we can insert a final proof for each side of a printed item. These proofs print out on the job ticket which is based on the components table.

 

I have a HISTORY table which is a one to many relationship from the job table. Each history record has one container field which can hold most anything from an EMAIL, FAX, RECORDED PHONE CALL, SCAN of any type of document, etc.

 

I also have an INVENTORY table which has a container field to hold a pic of what each item in inventory looks like. I know that may sound crazy but we maintain a rather large inventory of some rather odd looking items and a picture is worth a thousand words when you want to confirm that you've looked up the correct item. These pics can obviously be LOW RES.

 

And then I have an X_Job, X_Component, and X_History table also in the solution which contain the ARCHIVED job records. These are EXACT matches to the JOB, COMPONENT, and HISTORY tables hence the reason I said 3 err 6.

 

I know many people tried to tell me to just mark the records ARCHIVED and leave them in their original tables but I was stubborn and created the three seperate tables for them because I wanted the ACTIVE jobs table to remain small and robust. So now whenever a job has shipped and is billed the operator ARCHIVES it. A copy of the JOB record and all the COMPONENT records for that job as well as all the HISTORY records for that job are copied into their appropriate X_ tables and then deleted from the ACTIVE tables.

 

I think it might be appropriate to create these three X_ tables as SEPERATE files outside my MAIN solution file. That would spread the images out considerably. The MAIN solution would than have only the images related to active jobs being worked on and the INVENTORY pics. Once ARCHIVED the images would then be split into 3 seperate individual files. While the HISTORY file may contain more images than the COMPONENT file the HISTORY images could be considerably lower res than the COMPONENT images. Obviously the JOB file would contain the fewest images. If size becomes an issue on these three files I could always just split them off as years. 2005 ARCHIVES, 2006 ARCHIVES, etc.

 

O.K. thanks again for the insight. I am off to implement this plan. I am going to seperate the 3 X_ files. There wouldn't be an advantage to keeping the 3 X_ files together in one seperate file versus 3 seperate files would there? Obviously keeping them together would cause the file to reach its limit faster so I guess unless there was a big advantage to that I shouldn't consider it.

 

I'm just glad that right now at this moment the architecture of my solution lends itself so well to splitting off a large chunk of that image data.

 

Cheers.

 

Randy

Link to comment
Share on other sites

Thanks One Guy! ... You have clarifed things immensely and now I am really leaning toward embedding the images simply to avoid the "broken links" issue.

I'm glad (relieved) you found the information helpful.

 

O.K. thanks again for the insight. I am off to implement this plan.

Uhh, perhaps you might sit back and take a deep breath.

 

The container fields appear in several places in my solution but the bulk of them are in just 3 (err 6) tables. And the beauty of it is that at the moment the solution is engineered to conveniently move 3 of those 6 outside of the main file.

You may be creating some headaches for yourself. A standard approach is to create One table to store all your images (Inserted, Referenced, or a combination of both, whether it is in the Main file or is created as a companion File ... see previous post). Rather than having container fields sprinkled throughout all your other tables, you would create table occurrences/relationships to the Images table. This will allow you to have related fields on the layouts of those main tables, showing (pulling) the images related to any particular record.

 

I know many people tried to tell me to just mark the records ARCHIVED and leave them in their original tables but I was stubborn and created the three seperate tables for them because I wanted the ACTIVE jobs table to remain small and robust. So now whenever a job has shipped and is billed the operator ARCHIVES it. A copy of the JOB record and all the COMPONENT records for that job as well as all the HISTORY records for that job are copied into their appropriate X_ tables and then deleted from the ACTIVE tables.

 

I think it might be appropriate to create these three X_ tables as SEPERATE files outside my MAIN solution file. That would spread the images out considerably. The MAIN solution would than have only the images related to active jobs being worked on and the INVENTORY pics. Once ARCHIVED the images would then be split into 3 seperate individual files. While the HISTORY file may contain more images than the COMPONENT file the HISTORY images could be considerably lower res than the COMPONENT images. Obviously the JOB file would contain the fewest images.

If you have a Sam's Club membership, swing by and pick up some Acetaminophen ... they sell a "double" pack, 500-count each, at a good price. What you're proposing is similar to storing a deck of cards in four different drawers, based on suit, or 13 different drawers, based on card value, or in a myriad of drawers, based on poker hand combinations, or ... oh, make me stop!

 

FM's inherent ability to search is going to be quite hobbled under this design. By moving a Job record to the deep-freeze, your users won't have a way to see all the jobs for any particular client, unless you build the necessary relationships ... which would "mirror" the relationships you've already created, to some degree.

 

Give this some more thought. Much more can be said, but I've got an appointment with a client. Let us know where you're heading.

Link to comment
Share on other sites

Hi!

 

Been in the trenches doing my other job, Graphic artwork.

 

I do understand the ramifications of seperating the archived records from the active records. I may think about this for awhile.

 

But what I want to know is why do you recommend all container fields to go into 1 table? That just seems a bit on the crazy side to me. If the container data belongs to a given COMPONENT record why would I want to have another relationship set up with a key field in the component record to point to the container record with the container data in it when I could just have the container field right there in the component record.

 

Can someone please help me out with this. If there is a good reason for it than fine. But please help me understand why I should do this.

 

As always I do appreciate your advice and insight.

Link to comment
Share on other sites

This thread is quite old. Please start a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share



×
×
  • Create New...

Important Information

Terms of Use