I'd like to know if there is a way to find things like:
- all layouts that contain a certain field
- all scripts that involve a certain layout
- all scripts that reference a certain script
- all scripts that reference a certain field
- all buttons that invoke a certain script
- all buttons that go to a certain layout
- all calculated fields that involve a certain field
etc. etc.

If it's not currently possible, I think it would be a very great
enhancement for a future FM version

aditsu (AT) gmail (DOT) com wrote on (10/25/2005):

That's part of why they charge more for Developer (7) or Advanced (8).

The Database Design Report provides all of that, except the "all button"
items.

Matt

--

I am using FMP8A (and previously used FMD7), but was not aware of that
report. I'll check it out, thanks.

Adrian

In article <VOo7f.6681$p_6.4637@trndny07>, "Matt Wills" <I'm (AT) Witz (DOT) end>
wrote:

Of course the Design functions have been in versions of "normal"
versions of FileMaker for a long time, so you can write your own
scripts to create most, if not all, of those reports fairly easily
using Calculation fields or Set Field script commands.

There was also a database somewhere that used these functions to give
you various reports, but I can't recall where I saw it. That was a
while back and it may not have been updated to later versions of
FileMaker.


Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)

Yes, FMD7 and FM8A both output this info to XML and HTML but try
searching this information.
It would be nice to be able to get the output into a searchable
database... say like FileMaker.

Well, FileMaker can import XML, right?

"FP" <a (AT) pottnerconsulting (DOT) ca> wrote

Yes, but oddly enough, it can't import its own output. Apparently the
output is not properly formatted. Go figger.

Matt

Bill Marriott wrote on (10/26/2005):



--

I beleive FM's XML import is limited to the dsoresult and xmlresult
schemas that it also exports.

XML is FAR too flexible and to just allow "importing" of a random xml
file. After all how would you meaningfully import an xhtml page... its a
valid well formed xml document - but it doesn't really fit into any
particular database. There are any number of approaches you could take
that make sense... including putting the whole file into a single field.

-Dave

In article <KqP7f.12633$c4.998@trndny03>, I'm (AT) Witz (DOT) end says...

Seems to me somebody should be able to come up with a suitable
transformation document to process that XML output. (Not me, I can't figure
that stuff out!) A pity FileMaker Inc. can't find the time to do so. Maybe
someone else out there in Usenetland could/would. I agree it would be very
helpful.

Bill

"42" <nospam (AT) nospam (DOT) com> wrote

FileMaker put together a 73 pg document "fmpa8_ddr_xml_grammar.pdf"
that explains there XML output so these guys aren't being lazy on the
job; it just doesn't seem right that every developer should have to
write an XSLT document to translate the XML back into a format that can
be imported into a FM database.

I guess my complaint is this, they give us the data in XML format but
ask any developer and they'll tell you that they need this data in a FM
file to check their work.

FM 5 or 5.5 had a DDR that would output to a FileMaker file, this was
good except you still couldn't search the file because of the way they
displayed related data. eg. find me any field that uses field "ABC" in
its calculation

I would love to see 1 file which has 1 table per type of item eg.
script, script step, field, layout, file reference...
And 1 cross table that has 1 record for every combination of 2 items
eg.
field "ABC" is a calc that references field "DEF" and "GHI"; this would
create 2 records in the cross table.

Ideally this file would be setup in the simplest way possible so that
any idiot, within reason, could pull whatever data they needed out of
it and relink it to suit there needs. The DDR file that FM 5 or 5.5
created was too complicated.

The guys that put together FM8 have to be intelligent, now take that
intelligence and use it to create a DDR file that a dumb user like me
can use without being confused but still gives ALL information. I
don't care if you break every rule of database normalization to do it
or if the file is 10 times bigger than it needs to be. I don't even
need it to look pretty. I'm interested in the data, nothing else!

Having reread this, I think I should have addressed this as a "Dear
Santa" wish list.