kennedy

Hmmm... is this just a bug in v5.5? Can anyone make this work with 5.5? Perhaps its time to upgrade to v7...

I've tried different JPEGs, don't think its that. How about this... here's the database! Its a trivial little thing... please tell me if you can get a pic to go into the container in Competitors. Thanks!! Scoreboard.zip

Yes, I've tried all the commands that I mentioned with "Store Compatible Graphics" set both ways. And I've also tried just saving a link rather than the graphics. And yes, its definitely a .JPG... the tiny view even appears on the desktop... so Finder sees it as a JPEG and has no problem shrinking it and displaying it. Any other ideas?

I have to solve this today. How do I put a JPG into a container field?? I created a simple database... number, first name, last name, and picture (a container field). All fields are on a layout... viewed as a list... I've entered a few records... all the data went in just fine... the container fields are all blank. Now, I want to put a small JPG into the container field. The JPG is sitting on my Desktop right now. I tried dragging it and dropping it on the container. Nope. I tried right clicking on the container, selecting Insert Picture..., and then in the dialog selecting the JPG file. Can't, the JPG file is grayed out... even though I am allowing All Documents. I tried using the Insert menu's Picture... command... same problem in its dialog. I checked the Field Format for the container field... it does allow entry. I checked the Options on the container field under Define Fields... nothing is checked... so modification is allowed. What am I doing wrong?? Thanks for any suggestions. FileMaker Version: 5 Platform: Mac OS X Jaguar

1) How do you put a JPEG into a container? Right click on container... insert picture... go to desktop where a picture lays... the JPEGs are all grayed out and not selectable... even if I allow all files or JPEGs!! What's the trick? I couldn't figure out this simple thing from the Help nor from this forum... I'm feeling pretty stupid right now. 2) I am building a small (200 record max) database of people... I want to take quick headshots of each person who shows up for the event and drop it in the database... and the database will be tossed at the end of the event. So, no issue on size of the file NOR with the photos getting moved. The issue is simply to make it as easy as possible to do this, without needing an expensive plug-in. Easy stuff is the goal. Suggestions?? FileMaker Version: 5 Platform: Mac OS X Jaguar

Does FM7 (or earlier) offer any functionality for managing two displays in OS X? Or should I just plan to carefully position two windows, one on each display? Here's the desired functionality: I want a simple file of: EntryTime Score Event Competitor and a related file with: Competitor Name Picture On the one display (the laptop screen) I want a list of the records in the first file such that you can trivially enter the next score (EntryTime is auto-entered). On the other display (an external screen hooked to the laptop) I want to divide the screen into 4 quadrants (one for each event) and display the competitor number, score, name, and picture for the most recent score in each event. What's the best way to do this with FM7? (Or FM 5.5?) Thanks! Version: Server v5 Platform: Mac OS X Jaguar

Hmmm... I must not have been clear... sorry. What we did, issue one print command, did indeed queue just one job... a job with 100 pages. What I noticed was that it took non-linearly longer and longer for each additional page to be generated into that one print job. Since it doesn't take FM any longer to walk through the pages on screen, I assume the speed issue in creating the print job is related to the size of the print file it is building. Soooo... I theorized that it might be much faster to actually just print one record in each job, and thus spool hundreds of jobs each one page long RATHER than what we did (spool one print job with all the pages in it). Thoughts?

Mac OS X 10.2.6, FMP 5.5, FMS 5.5 A Minolta PostScript laser printer... our fastest printer in all other situations. No, I didn't try another printer. I could try a normal HP inkjet... or a Lexmark inkjet. The Color Laser Printer would definitely NOT be a good idea. Not sure the size of the print job... I think the printer has 12-16MB... I'll have to double-check that when I go in. Yes, I mean records. Thus, each print job would be one record... and there would be many, many print jobs queued. Well, its not a "report" layout... just the normal form that you'd input the basic Family information on. And clicking the arrows to walk through the records has zero delay... instantaneous. So, in printing these, there should be no noticable delays accessing data over the network, finding the next record on the FM Server, computing portals, computing calculations, rendering the layout, etc. Its something specific to spooling the print file... so, my first guess is that it does a poor job of generating/spooling large PDF files. Hence, my thought of scripting the printing of individual pages. If you've ever looked at my "The Works" starter template (Aqua LAF), its basically that. So, the graphics is simply little aqua buttons. All help greatly appreciated. I'm obviously going to need to experimentally try some things... so, in the interest of time, I'd like to try as few things as possible.

I want to update all my member info. So, rather than have people fill out the same old form, I want to print the FileMaker layout for each family and ask a family member to correct anything that's wrong. So, that means printing the layout for each of about 2000 families. We decided to start with the first 100... did print... said to print pages 1 to 100... it started spooling them, but as it went, it got slower and slower and slower. And then when it started printing to the printer, there's a notable delay between each page... not the normally swift printing that you'd see printing a 100 page document from Word on that printer. In the end, it took about 30 minutes for those 100 pages. At that rate it'll take 10 hours to print all 2000... if we do them in blocks of 100... if I just spooled them all, based on how it was getting slower and slower, it might take forever! I'm looking for some tips on what to do to speed this up... Assuming spooling the large file is non-linear, I suppose I could write a script to print the current layout and then go to next and repeat until done. Thoughts? Would that be faster than using the FM print dialog to print all the records? The layout has some FM graphics on it... is that what's causing the slow printing at the printer? The layout is not a report and has no summary fields... just a normal layout form. It does have one portal listing the members of the family. That list needs to be there. But the relationship is very simple keyed relationship. What else might make spooling slow? What else might make the printing at the printer slow?

I will second the recommendation to avoid meaningful barcodes. Rather, you simply want a unique ID that is highly likely to remain unique forever and to never change forever. You may not see it happening now, but consistently all meaninful codes eventually become a huge headache. Consider this one of the fundamental laws of good database practice: no meaningful ID codes! I recommend using CaptKurt's UniqueIDs for barcodes, or something similar. I use a shorter variation of his UniqueIDs (to keep my barcode length more manageable)... you can check it out in "The Works" template that I posted to the Sample Files forum. You can find the article on CaptKurt's UniqueIDs in the Articles forum.

Anatoli, I agree with that statement. Problem is, you are blaming the wrong thing! Its not OS X shutting down and corrupting databases... its FMS shutting down and corrupting databases! So, its not OS X that is the piece of crap... its FMS. But that's not unlike the piece-of-crap security that FMS and FMP offer (in contrast to the solid security that OS X provides). Why on earth FMI would not quickly fix this FMS bug is beyond me... unless they cannot reproduce it. They've said "there have been reports of"... but given I have never seen it in all the times I've shutdown and restarted FMS on my OS X machine, I have to wonder if they've never been given a reproducible bug report on it so they can get it fixed. I wonder further whether the reports they received weren't actually something different. Hmmmmm...

Yes, and in both those records, CompanyProperty would be set to the Company that is owned by the two (the person and the other company); while OtherProperty would be null in both. Exactly. One way is to create a field Name in Owners file which is a calculation: Case( not IsEmpty(PeopleOwner), PEOPLEOWNER::FullName, not IsEmpty(CompanyOwner), COMPANYOWNER::CompanyName, "!Error!") Then in the portal you can just put OWNERS::Name.

Yes, the relationships are fixed... and they all are there... you "dynamically choose" by which one you use for specific purposes. For example, when you are setting up the portal in your Company file to display all that it owns, you use the PROPERTY relationship, accessing fields PROPERTY::CompanyProperty and PROPERTY::OtherProperty. The Owner records that relate to a PeopleOwner will simply not show up because their PeopleOwner fields will be blank. You say "A different Owner record would have a relation between Owners::OtherProperty and Companies::CompanyID." First, the relationships aren't record-by-record. Its just that the relationships that don't "apply" will just not match because they have blank values in those fields. Second, there will be no relationship between OtherProperty and CompanyID. Does that make sense?

Create a second field with 24 hour time OR proper am/pm designator, and then create your sort on the 24 hour time OR on am/pm followed by 12 hour time. You can sort on fields that you do not display. And those hidden sort fields can be simple calculations from your time field such that your user never needs to know their there... unless they are building custom sorts.

If when looking at a Person or Company you want one portal with all the stuff they own (rather than one for the Companies they own and one for the Property), AND when looking at a Company or Property you want one portal with all their owners (whether Company or Person), THEN one option would be to create a single additional file "Owners" that has fields PersonOwner, CompanyOwner, CompanyProperty, and OtherProperty. Make sure that only one of the two Owner fields is set at a time and that only one of the two Property fields is set at a time. Then, for example, Company will have two Relationships, one called OWNERS which matches its ID to the CompanyProperty field in Owners, and another called PROPERTY that matches its ID to the CompanyOwner field in Owners. Similar to the former in the Property file and similar to the latter in the People file.

Ugo, I think that will work as long as we are guaranteed that no Start and no End will ever be during the weekend. Logically, they shouldn't be... but if they have a convention of putting a Saturday night end in certain situations, that would have to be fixed (or the more complex formula used). Same issue with the Time calculations in general... plus we need to talk about shifts if we are computing seconds rather than days. Most shifts don't run midnight to midnight, as the latter two computations assume. But, if we can assume the start and end times will be during the working shift, then we can easily accommodate any single shift (e.g., 8 to 5).

Need more info... Are the fields of Company a strict subset of the fields of Property? Are the fields of Property a strict subset of the fields of Company? Will there be other entities for which Property will be a strict subset of? If neither are strict subsets, what are the fields that will be common between Property and Company?

Off the top of my head (untested), something like the following pseudocode should work: RawDays = EndDate - StartDate Remainder = Mod(RawDays, 7) FullWeeks = (RawDays-Remainder) / 7 Cover = DayOfWeek(StartDate)+Remainder ExtraEnds = Case(Cover >=7, 2, Cover=6, 1, 0) Days = RawDays - (2*FullWeeks) - ExtraEnds

Sorry, no links for you. I haven't gotten to the charts part of my project, so I haven't really looked into it deeply. Early on, I checked a few out to verify it would be possible later; but then I stopped. However, as I go through various of the tips and samples and such FM sites, I typically find yet another chart example with some interesting ideas. Even russCalcs from Oz has some basic chart stuff. Maybe some names will help: ChartMaker Pro and CCVbar Light. I think I've seen some on fmfiles.com, Osborne's site, maybe Cologon's site, and some other places I'm not thinking of right now. (I suppose I should take better notes.)

Take a look at some of the non-plug-in graph solutions. They use various tricks to allow them to display stacks of objects of different colors based on the values of fields. There are numerous of these.

Windows an "excellent multithreaded preemptive OS"! Wow, and I didn't vomit while typing that. I could go with "well tested" and maybe even "robust", but not "excellent" (ick). That's like saying "Outlook is an excellent email client". FWIW, I can say "ever since OS X Server 10.1 was released, our FM Server has never crashed, and performance has been more than adequate (no waiting)". And OS X truly is an "excellent multithreaded preemptive OS"! Independent of the "my OS is better than your OS" debate, I'd love to hear answers to the queries above. What is it that FMS actually does? What is it the clients actually do? And what information/dialog moves between the two? Thanks for any enlightenment.

You can find Bob's great SoftDoc utility here. It won't do the ER diagramming, but will allow you to do many analyses based on the info. And you might be able to craft an export to Visio or something (if you do, please post to Bob's SoftDoc thread for the rest of us to use!

I've never had the luxury of FMD, so I am not sure how well a DDR will work for you. So the following might be helpful... For those without FMD, the following will definitely be helpful... Bob Weaver's SoftDoc utility will create a FM database out of your databases, which you can use for all kinds of analyses (like "where used"). Check it out. Brian

And let me further stress those questions. In a security-related thread, it was asserted that FMS is a "thin-server"... that it does not execute any of the DB functionality, but rather just serves up the records/files to the FMP clients that do all the work. All FMS does is maintain the record locks from each of the FMP clients so that you don't have two FMP's changing the same record at once. Based on that, I would not expect an FMS-hosted sort to take any longer than an local sort... other than the time for FMS to spew the whole file to the FMP client. My experience would support that, as I don't see much slow down due to FMS vs. FMP. Is there a technical writeup anywhere that truly explains the protocol between FMS and FMP, which does what, and how performance is impacted? Also, I don't quite understand how FMS could be truly multi-threaded on OS9... didn't know that was possible.

They have their server on Mac... OS9 or OSX?