Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 6183 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted (edited)

Hello group. I've tried this question over at FM Cafe and apparently that board is not heavily used and thus not heavily monitored. I see lots of questions that have largely gone unanswered. Here's mine:

We have this client control application in FM5 (old as dirt) that was written by someone else (who is long gone from the org). As a novice user, I've been trying to get FM5 to export the entire database so we can move it to another more robust and networkable platform. Our little non-profit charity can't quite afford the steep upgrade path to FM9. Anyway...

In this application, there is the Main (name, addrs, phone no, DOB etc.) database. There is a seperate Financial database where client income/expense budgetary data is loaded. There is a Household database wherein household member and composition data is stored per client. Then there is the daily contact/entry log file (called FollowUp) for the clients. All these dependent databases use Rec No's in their Relationship to/from Main. FM5 will sucessfuly export Main by itself OK. But I need the FollowUp & Financial & Household comp records that go with it.

Every time I add FollowUp's fields to the Export list, after a real short burst of disk activity, FM5 crashes (Windows - FM has encountered a problem and needs to close...) and I'm back to the desktop. I am able to run export again, selecting just the fields in FollowUp or Household or Financial solely, the export runs OK. So anytime I "touch" these other sub-databases in concert with Main, it poops out. And, to make matters worse, I've just corrupted Main somehow. Fortunately, I had just backed it up so it's cool.

I've run chkdsk and defragged it, cleaned out temp files etc. We've scanned for viruses and spyware using standard protocols. FM is not telling me to "recover" FollowUp or the other secondary databases nor Main so I assume that is good news.

I'm just trying to pull off the data and move on. I'm hoping someone can tell me of a utility or other nifty technique I can use to get what I need off this thing.

Thanks and I'll be anxiously awaiting some guidance!

Edited by Guest
Posted

a few comments:

1. many of us still use FM5 & FM5.5, so not so old as dirt. It is drop dead simple, and extremely reliable. FM6 was the last great version of that era, if you can find copies on ebay

2. each FileMaker file is a "table" of data, and probably best to export each separately. If you find the table / data arrangement is clumsy, you could later fix this in your new application. And yes, the tables are tied together by a "key" field, like record number.

3. what application are you considering?

4. on crashing & corruption, I have posted some tips here http://nyfmp.org/1/57

Posted

Hi Greg - thanks for your interest in my (our) problem.

OK, I guess I will have to export each individually as you've pointed out because that's the only way FM will do it. Probably because of some corruption somewhere in the tables. I've read (and bookmarked) your article on corruption. Looks like there's not a lot of hope. Luckily the solution still runs but for how long? I get a sinking feeling we're headed for catastrophy.

The problem with exporting each individually is: How am I ever going to reassemble these? I don't see any record no-s in the tables displayed - though I know that record no-s are "keys" from an inspection of Define > Relationships. That's why I was trying to get all the tables to export as one .csv file figuring maybe the import on the other side would help straighten it out. There are 860 client records and over 5,000 of those Follow-Up records in the Follow-Up table!

We want to move this data to a web-enabled application. It's fine for a standalone and has worked pretty good to date. But with our director and several other key members of our org off site, I have this vision of having the database updatable and queryable from off site. Right now, for instance, if we want a particular record to be shared for action, I have to print, scan/email or print/fax - not good for any number of reasons. Do you have any further suggestions to guide me in reassembling the related tables correctly?

We're thinking of Oracle XL. It's free and the server (we just got some free server space) will handle it.

Thanks Greg for your time. I'll stand by for any words of wisdom...

Hoib

Posted

> I don't see any record no's in the tables displayed

Check Define > Fields, are they there? per my article, be sure to export all text, date, time & number fields, as file type "MER"

note: if a relation depends on a "global" field, you may not "see" the value

greg

  • 3 weeks later...
Posted (edited)

I'm back again, Greg. I had to take a break to do some other things.

The names are indeed present. When I export as a MERge file though, I can't read it. Tried Excel - it won't show what we're looking for. What I need to do is export all tables, all fields and provide the programmer who is helping us with a matrtix/spreadsheet that has the field names listed across the top. I see and understand the export field selection dialog. The export works but I do not get the actual field names associated with the data, like "Last Name", "First Name", etc. across the top (or anywhere else for that matter). In this application and data there are dozens of dates, text entries, numbers that without a label at the top, are near impossible to figure out. Yes, I can tell where the City or State or ZIP area s those are pretty explicit. But where we have just a plain dollar figure, for example, what dollar figure is that? There are even many columns that come out blank, top to bottom. Would like to know what those are.

I'm trying to get FM5 to give or tell us the field name labels so I can see what data is what in a form that we can use to import into the new prog.

Doesn't FM have that?

Edited by Guest
Clarify
  • 3 weeks later...
Posted

Export in merge format is exactly what you are looking for. It puts the field names as the first record in the export.

So if you can go to each file ( table) and find just one record and do a merge export, you will have a 2 record table with the first record being field names and the second being representative data.

Take these export files and drop them on excel to create spread sheets.

HTH

Dave McQueen

Posted

Here's what I wound up doing. This may or may not help the next person to encounter this issue.

Our version of FM5 -WILL NOT- completely export the database! As soon as you request an export, FM5 runs for a moment then crashes with the familiar "if you were doing anything save it. We apologize for any inconvenience...blah-blah-blah..." Strangely, when I export say only one or two tables, it goes OK but no field names, even when outputting as a .MER file. They just don't appear. I could have perhaps exported one table at a time but what a mess to try and re-assemble all this. Who has time? So some sort of corruption has crept in to either the data tables themselves or more likely the program files themselves. It's hard for me to tell what the source of this problem is. I was ready to give up - but, after thinking about it a bit more, here's the good news:

I downloaded and installed a trial version of FM8 on my home system. I took copies of the raw FM5 datafiles and ran them through on FM8. After some playing around and getting through a number of "conversion incompatibilities" as each table is called, I finally got a set of fm8 files that brought me to a working application/solution using FM8. OK, now to export - the process is almost a mirror of FM5 -but- FM8 does run the complete data export all the way through with no crashing. And, outputting as a .MER file permits us now to see those enigmatic field names in Excel!

Talk about a workaround! So, even though it's not neat and clean, at least we know how to preserve our data and hopefully our programmer will be able to reassemble the data into the new package.

Thanks all.

This topic is 6183 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.