Second screen ? Second PC ?
I don’t think it’s a good idea to open the Manage Database and then continue to use the file as a user, even if you could (and there are ways to do this, for example using two copies of FileMaker). There is a danger that you might forget that you shouldn’t introduce changes in the schema while modifying data. Saving the image of the relationship graph and then closing the Manage Database window is safer.
This is part of my best practices.
What I do is take a screenshot and display that. As far as I know, there's no way of keeping the RG open whilst you use the DB.
Thank you John.
Screen shot (or print to PDF). I do that all the time!
Thank you Beverly
Thank you Beatrice. Fair warning !
I do this sometimes in development. FMPA and FMP installed on same machine. Rare cases where I need it.
Usually more helpful when I need to compare the RG between two files.
::raising both hands::
Don't do that on a live, in production database. I triple-second what BeatriceBeaubien said.
I also agree with Beatrice Beaubien and Joshua Ormond . Do not use this on a production system and do not make it a regular part of your development routine.
Even when I've undertaken some experimental modifications on a Backup copy of our main system on my development server, then want to incorporate some improvements into the main system, I have both files open and have to be incredibly careful to copy and paste between the backup and live solutions. Having the server name in the window's title certainly helps, but you still have to be extremely vigilant.
As Beatrice and Josh advise, it's certainly safer to make these changes when the production system is not in active use. and only when you have a recent backup for when you mess up.
my puny 2c!
Thank you all. Got the message loud and clear. Not going to do it !
As a follow-up to John's method, screenshots offer an advantage over FMP's native E-R display, in that FMP's relationship diagram is perforce dynamic, whereas screenshots can be timestamped, archived, and used for (for example) before/after comparisons, or fully expanded TO boxes for detail vs. all collapsed ones for overviews.
Thank you. Got the message loud and clear. Not going to do it !
Not and get any work done. While the RG is open it locks the schema and may lock tables or even the complete file. Nothing like having your users up in arms because you’ve locked the database.
I suggest you take a screenshot or print out the RG for a reference.
It is never a good idea to leave the RG open for any longer than absolutely necessary. Do your review, get a screenshot, make the change, and get out of the RG.
BTW, making changes to indexed fields in tables with large data sets can cause very long delays for all users as the table/database update occurs. For example: it's best to do calculation changes to unindexed fields set to auto-index as required. Then do something to trigger the index creation after the schema has updated. And try to schedule it when it will have a minimum impact on users. If you use ‘robot’ computers to perform auto-processes then disable it while the file is updated. You DO NOT want the two fighting for control of the table/file. The robot will lose and hang and may even cause loss of data integrity.
Everybody has been suggesting screenshots? Printing to PDF gives you scalable graphics and searchable text.
And, another irritation, though minor, to me is FMP's high modality. That is, it seems so often that, unlike other dev products I use, I can only have "one of these windows" open if I try to open another one "of those windows"...I can't. I then have to back out of the first window (close it) to be able to open the second.
Why not let me open 10 of "these" windows and 5 of "those"?
Why so modal?
The FileMaker Product Roadmap has something to say about this . . .
While the RG is open it locks the schema and may lock tables or even the complete file.
I could be wrong, but I've been under the impression that schema only locks the moment you view options on a field definition or relationship and remains locked until you close the Manage Database window. Otherwise, you are (generally) safe to explore field lists and the relationship graph, even to the point of printing field definitions.
If you are on a Mac, you can run two copies of FileMaker by using the Terminal to open the application in another process. By my interpretation of EULA, this is legal because you are still one user running on one machine. (Let me know if I'm wrong and I'll stop doing it.) I only use this when I am integrating functionality from a FileA to a FileB.
Use the Terminal and issue the command:
open -n -a "FMPA16" (Note: I rename my executable image from "FileMaker Pro Advanced" to "FMPA16").
In the second copy of FMPA you can open a second file for cross-referencing graphs, scripts, layouts, etc. between the two files. I've never tried to open the same file twice as I assumed I might damage the file. However, if you dupe your FileA in order to have a FileB, then you can have the same file open twice.
I'd like to add the following:
It has not been uncommon that I find myself working on an unfamiliar and/or complex solution where (for all the reasons mentioned here, and more) it is not possible to open up the Manage Database window.
In such cases, the Data Viewer, in conjunction with a handful of often overlooked FMP functions, can be your best friend.
Certainly, the above will not provide you with a direct graphical depiction of the relationships, but much of the information that you might seek from Manage Database is still available to you, and, as with many things, the more that you practice, the easier it becomes, to the point where you may find yourself seeing the graph in your head, based on the responses provided by methodical queries in the Data Viewer.
In particular, the functions that I use all the time are:
RelationInfo will allow you to see what Table Occurrences are related to a specified Table Occurrence. Repeated use will allow you to understand the trajectory from one TO to another, as this function also returns info about the constraints used to relate the TOs. To me, the output is visually cumbersome to parse, but it does get easier to grok with repeated use.
Among other things, FieldType will let you know if a field is global or not, as well as the data type. I also use this function to check to see whether a field is indexed or not, so that I can avoid running a Find request against an unindexed field in a tall table.
ExecuteSQL I regularly use to see what the Table is that is underlying a particular TableOccurrence, or to see which TableOccurrences are built off of the same base Table. It is also useful for seeing a listing of the fields defined in a table. The two tables that one queries against to do the above are named FileMaker_Fields and FileMaker_Tables.
Andrew Duncan of DataBuzz has a nice post that will get you up and running with how to query these meta-data tables:
There is a lot of up-to-date schema and relation information available to you without having to open up Manage Database. I won't try to claim that it will be a walk in the park to use (especially if you are after a visual/graphic representation), but I will say that the above functions will give you the wherewithal to obtain answers to questions that you might have as you are treading carefully in an unfamiliar system. It was always my hope that I would have some time to throw together an easy-to-use UI that would wrap up some of these functions and give us a list-oriented GUI that would help each of us in our workday for those cases where one just can't/shouldn't be poking around in the schema UI of FMP. As it is, that idea has stayed on the shelf, but, in the meantime, I gained fluency with typing some standard lines into the Data Viewer, e.g.
• ExecuteSQL( "SELECT BaseTableName FROM FileMaker_Tables WHERE TableName = ?" ; "" ; "" ; Get( ActiveFieldTableName ) )
• FieldType( Get( FileName ) ; "SomeFieldNameHere" )
I hope that this may be of help.
bigtom wrote: I do this sometimes in development. FMPA and FMP installed on same machine. Rare cases where I need it. Usually more helpful when I need to compare the RG between two files.
Usually more helpful when I need to compare the RG between two files.
Why not two FMPA's? That is what I do.
I often give FMP a large task which will keep it busy so I open a second instance using an applescript in the dock and get to work on something else.
set s to quoted form of "/Applications/FileMaker Pro 16 Advanced/FileMaker Pro Advanced.app"
do shell script ("open -n " & s)
I have a Surface Pro with yesterday's backup loaded on it and I am able to run them side by side if/when needed. The Surface is a stand-alone and not connected to the live file or even the network for that matter.
Managing the desk space can be challenging if you have a small desk especially if connecting an external keyboard, mouse and monitor to the Surface.
I have found that on my MacBook Pro I can duplicate the FileMaker Pro advanced folder in the Applications folder. Rename the second instance with a V2 appended and drag a shortcut to the dock. The open either copy or both as needed.
Why limit yourself to only two instances. Save my code as an applescript application and place it in your dock. Each time you select it you'll fire up a separate instance of filemaker.
You can also run a Database Design Report (DDR) and use a tool like FM Perception to quickly isolate and analyze the relationships in the file. However, you can't edit the DDR and then reimport into FM to make changes (yet... teaser on this feature for future release at DevCon 17).
Retrieving data ...