Can an existing solution become a FMP7 table?

[stann]

Can a filemaker file be totally brought into FM7 as a complete TABLE?Sorry I just don't know this.

THANKS

STANN

FileMaker Version: 7

Platform: Mac OS X Jaguar

[jasonwood]

What we used to call "database" or "file" was actually a "table".

Normally, the term "database" means multiple tables. FileMaker 7 allows for multiple tables per file so now, like the rest of the world, we can call the whole solution a "database"/

So yes, a single file can be brought into FileMaker 7 as a table.

If there are multiple files, I guess you'd import each file into its own table (if you're making a single-file solution).

[stann]

But how is it done. I have some solutions that are great as they are. I would like then inside a FM7 database as a table. But how is it done. and does it keep its original look and functionality.

Thanks

Stann

[Singlequanta]

If I may, I think what Stann is asking is....

When converting older FileMaker solutions wherein there were multiple files,

can FM7 pull them all into a single file with multiple tables or does the converted solution need to remain as individual files.

I haven't played to much with conversions like this, i just started working with new solutions in 7 so if anyone else knows the answer i'd be keen to find out as i've got heaps of <FM7 stuff to eventually convert

[Ano Nimus]

FileMaker has no tool that can migrate old solutions such, that multiple files in the old solution become tables in one file in the new solution. After conversion, multiple files will still be multiple files.

A company called New Millenium is creating a tool called FMrobot (I hope I remembered company and product right) that can do this, however.

[CobaltSky]

Ano Nimus said:

A company called New Millenium is creating a tool...

Past tense. It's already available:

http://www.nmci.com/Product_Overview.htm?pid=P77YJCFQ66NXQYB0LCXW

[Doug Leib]

I'm beginning a conversion/rewrite project myself right now and this is what I've found so far. The only tool I've found so far to convert a multi-file/database solution to a single file FP7 solution is New Millennium's FMRobot as mentioned above. It is only available for Windows at this time. I haven't used it since I am still evaluating whether to convert or rewrite.

In short I am leaning towards a rewrite after a conversion attempt fraught with problems. (complete with application crashes) In all fairness a less complex solution might have converted fine. The solution I am working with is complex with a lot of controlled navigation and an assortment of primitive (FP4) era conditional value lists and other such awkwardness.

As a result I am inclined to rewrite. I think that by running the old version and the new rewrite simultaneously I can cut, paste and import thereby speeding up the rewrite process. This will help to carry forward useful and complex calculations and scripts while allowing me to tweak them as I go.

And finally... a bit of good advice I've taken to heart. In order to fully benefit from the new features and methodologies found in FP7 you must first take some time to learn FP7. This is true whether you are converting or rewriting. Otherwise you will find yourself solving problems with legacy (obsolete) techniques rather than new and improved FP7 methods.

After all... isn't that the point of upgrading?

[Leader]

Yes.

For such a great product, FM 7 has some of the poorest documentation I've ever used. I stumbled across the solution almost by accident, trying things out of frustration at 2 in the morning.

Bear with me as I'm working blind... I don't have FileMaker on this machine. But in essence, this is what I learned:

Step 1. From within FM 7 Pro, OPEN your older version's main database. (It can be any, but it's advantageous to suck your most editted table in first.)

Step 2. Then, use the IMPORT command to suck in the remaining database descriptions and scripts from your other database files.

(head smack)

Hey, FileMaker: Make life easier by giving us decent manuals.

[MoonShadow]

Step 1. From within FM 7 Pro, OPEN your older version's main database.

Don't do this!! Drag your existing solution to an FM7 icon and let it convert the entire folder at one time.

Step 2. Then, use the IMPORT command to suck in the remaining database descriptions and scripts from your other database files.

Import the other databases into main? Suck in your database descriptions??? Please everyone, thoroughly research before applying this advice. There are great Migration pdfs available from FileMaker. Take the time to read them and do it right.

[Ano Nimus]

Leader said:

Hey, FileMaker: Make life easier by giving us decent manuals.

No, please! Not even more! My eyes are turning square from reading all those PDFs.

I have to say, by the way, that I find particularly the 88 pages of conversion guide a very usefull bundle. In my experience, if you follow the checklist (talk about a decent guide, how much more clarity can one wish for?) carefully, you can convert horribly complicated solutions without getting major trouble.

[Leader]

Post deleted by Leader

[Leader]

I didn't say MORE MANUALS.

I said BETTER DOCUMENTATION.

And it wasn't just one conversion guide, but what... 3? or 4 conversion guides? So 88 pages + 33 + 25 + ?

The fact that most people here didn't know the answer and that you and I both missed the squib in the manuals shows the shortcoming. Every hour vainly searching for an answer is an hour of development lost.

[CobaltSky]

Leader said:...why did 5 people just give Stann the wrong answer?

As one of the five people to whom you are presumably referring, I find that comment both inaccurate and personally offensive.

In my personal estimation, the least accurate answer provided in this thread so far was your own.

Moreover, FWIW, I find the overall quality of documentation available from FMI to be excellent and I respectfully suggest that if *you* are unable to find what you are looking for, or to understand it when you do find it, perhaps that is a reflection on *you* rather than being the result of any deficiency in the abundant, thoughtfully prepared and well organized documentation.

[Leader]

Although MoonShadow is right, I suggest not doing it that way if you're facing any complexity, as indeed some of the guides touch upon. The reason is that you will probably want to repackage your files which drag'n'drop won't let you do.

So for example, if you want to package your tables into one or two files and your interfaces and scripts into another, only OPEN/IMPORT will allow you do do that. (And in a continuously working on-line environment, it makes sense to separate out your tables from your scripts and interfaces.)

[MoonShadow]

And you are suggesting you OPEN your Main file - the one in which you wish to keep your scripts? If you open your Main file (prior version) in this way, FM7 can not find its related files. It does not provide an fp5 option in the file dialog from which to repoint to them. Your only 'out' is to cancel and you will break your relationships.

Are you suggesting it is better to Open this main file and then continue your design using it? I would rather not. It is when facing a complex construction that I would particularly want to convert all files, so I don't have to see <Field Missing> throughout my scripts and calculations. I believe one should convert them all first to preserve the integrity of the solution. And then proceed from there.

[Leader]

Well Cobalt (nice handle BTW), all our efforts here were aimed at assisting Stann. I didn't say your answer was wrong, just that no one had directly answered his question, and I stand by my answer for the reason just above since it does answer the question he posed.

As far as manuals go, I have literally gone through hundreds of manuals over the years and even written a few as a commerical developer. The law of technical writing is to elucidate accurately and easily, and if only 10% of the audience fails to find the information, then we have failed the reader, not the other way around.

My lady has been the manager of Research & Documentation for a 'large central Florida theme park' and now for a large pharmaceutical company, and their quality of manuals is paramount- it can literally spell the difference between life and death. I've seen the intense efforts her teams go through stiving to find better, clearer ways of presenting information. For most software companies, manuals are usually a reluctant afterthought, primarily the reason authors are able to successfully flood bookstores with software how-to books.

The FM manuals are not horrible at all, but IMHO they are not at the top of the pile either. But of course that's an opinion only, and not to be construed as a fact, nor is an opinion about manuals meant to insult a person.

(Unless, of course, you were the manual's author, in which case it's still the manuals I'm complaining about, not you.)

The bottom line is that we all would like to think Stann has benefited from our combined efforts, yours, mine, everyone's.

(And I still like your handle.)

[Leader]

MoonShadow- I wrestled with the points you posed, and frankly with the newness of FM 7 I'm still ironing out in my mind which is best. You were very considerate not to point out that my suggestion breaks an essential rule of software: If it ain't broke, don't fix it. (Although I found I had to chase down all those pesky .fp3's, .fp5's, and .fp6's anyway.)

Clearly, if one were vesting in a new FM 7 application, breaking out scripts and interfaces into a separate file makes operational sense, as a couple of FM's manuals currently suggest.

For a conversion though, your recommendation comes down on the side of safety, and that's a tough position to argue with. No one should have to deal with frangible code if they don't have to.

If you don't mind my modifying my comment to accomodate your thoughts, I think I'd probably be guided by this:

(a) If an application package is volatile in terms of ongoing changes and updates, I'd be likely to split out the interfaces+scripts from the data.

(: If an application is mature and not subject to ongoing alterations, clearly your path is advantageous.

[MoonShadow]

(: If an application is mature and not subject to ongoing alterations, clearly your path is advantageous.

I believe you are missing my point. Using Drag and Drop (drag folder to FM7 for conversion) is still the best way, regardless of how you decide to structure under FM7.

I too separated the interface from the data. I converted properly, created the new related tables in my main file and imported the data. I left the related FILES there (and still related to Main). Because it was easier (and safer) to then go through my scripts and calculations (in my new main file) and respecify the correct Table/Field, because the old file/field was still listed for a template. Respecifying was a snap. You are right on one point ... it is a safety factor.

I would not like to be in the position of accomplishing the same thing while viewing <File Missing> or <Field Missing> through a complex structure - too much room for error. And I believe that attempting to do so would be unwise. I would rephrase your 'If it ain't broke, don't fix it' to 'If it ain't broke, don't break it.'

[hartmut77]

I would like to know if the old filemaker solutions can become a table in Filemaker 7 and two or three files could be combined in the one database?

[Leader]

The short answers are Yes (with qualifiying that you might have tweaking and some script alterations) and Yes (you can combine files in pretty much way you want.)

You may have to rework some formulae and scripts and make corrections of file names which was what MoonShadow and I were tossing back and forth.

[alta_flyer]

I Converted a fairly Complex Series of Files from a Version 6 Database Using the recommended method in the PDF. The Transition appeared to go smoothly but problems have come up with the "Related Files" function of Version 7. The biggest problem is in how The new Database Imports records. I tried importing a "Found Set" of 1900 records and the Table Imported all 53,000 records from the "Source Table".

[Sabrina]

In response to the post about FMRobot, I have tried contacting the company and for some reason they aren't contacting me back. If anyone has an "in" with NMCI, kick them in the pants for me and let them know they are going to lose a customer if they don't get their act together. I don't have time to chase down a salesperson to convince them to sell me their product!

I talked to FileMaker about the importing and at first they sent me to their tech line and wanted me to pay $45 dollars (or $3 a minute) to figure out if the product would be advantageous for me to purchase. I did call back later and got a sales rep that knew what he was talking about but really! Why do they think we have time to chase them down for answers? What Leader said about the documentation applies to my frustrating search for answers BEFORE buying, every hour spent chasing is an hour taken from developing.

I finally came here because I'm not getting straight answers anywhere else! Stann, thanks for your post. I had the same question and it's been answered well. I hope you found the solution you needed. Thank you all for posting answers found and say a quick prayer for me to find out the last things I need to know!

(Next time I'm coming here FIRST! Silly me thought the actual company would answer my questions quicker . . .)

[CobaltSky]

Hello Sabrina,

In my experience, the folks at NMCI are generally very responsive - among the best.

But I'm also aware that they have been *very*very* busy of late and I would guess that your enquiry is in a queue that they are struggling through.

You may get the answers you were looking for from elsewhere (the forums for instance) but I'm afraid if you want to wait for the 'official' response you may have no option but to remain patient. I realize that is cold comfort if you have pressing decisions to make...

[Wim Decorte]

Yes... even MORE. Once you realize how different 7 is from 6, you'll want read all those migration documents.

HTH

Wim

[James Collins]

We have a 15 file database in FM6 which we are looking at converting to FM7. Most of the files use calculations between each other so would there be a performance advantage in combining all the files into a single multi-table file?