Problem creating DDR

[flook]

Help

I've been trying to create a DDR to check a database file, problem is every time it's about half way through generating it flags an error "invalid character (unicode 0x1D)". Does anyone know what this means and what I can do to fix it?

Many thanks

[Wim Decorte]

Try the same thing on Windows. See if it gets any further. If not, can you tell where that character is by looking at the unfinished output the DDR created so far? If you're able to deduce in what file on what layout or field def or script def or account,... it happens maybe you can leave that object out.

[flook]

Unfortunatley I don't have access to a copy of Developer on a PC plus the File has about 25 tables in it now and a lot more scripts.

How will I know an invalid Unicode character if I see one?

[Zero Tolerence]

Your copy of Developer for MAC will work on your PC, you just can't leagally run them both at the same time.

[RalphL]

The FMD License says:

"You may install and use only one copy of the FMD Application on a single computer running Mac OS and one copy of the FMD Application on a single computer running Windows." There is nothing about not running at same time.

[flook]

Interesting! but doesn't solve my problem as I don't have a PC I can easily access. Any other thoughts on how I can find out where my stray unicode character is.

Flook

[Wim Decorte]

Have you tried looking at the output the DDR created as it failed?

[flook]

Yes It's broken the summary page is there but all the links are empty.

[flook]

Have now tried creating a DDR on a PC, same thing happens "invalid character (unicode 1X0D)", is there anything else I can try. I'm worried that if I don't find this invalid character at some stage the whole database will corrupt.

[QuinTech]

Forgetting about the DDR for a moment, try this:

Create a layout for each table that shows all fields. Then find all records and flip through them one-by-one (using Ctrl-DownArrow). If there is junk data in one of your fields, FileMaker should crash when it hits that record.

I haven't seen the issue that you're talking about, but it does sound familiar to something we see from time to time in version 6.

Jerry

[flook]

Have tried that and still had no luck, so I decided to delete all records from all tables (creating back up first!) and still came up with "invalid character blah blah blah". have been through all 27 tables/757 fields and cannot see anything that shouldn't be there. I will not however, give up as I think finding the invalid character will prove a rewarding experience....

must get out more!

[DykstrL]

Sounds to me that you have a layout that has one or more corrupted elements on it.

Using QuinTech's method, go to each layout, go into layout mode and maybe just move something on that layout, then move it back, then go back into Browse mode. If the file crashes, or gives an error message, then you know that's the bad layout.

[QuinTech]

From this unicode reference:

character = GS, decimal code = 29, hex code = 0x1D, oct code = 035, description = group separator

"Group separator" -- I'm not sure what that means. Maybe it will ring a bell for you.

Now here's a crazy thought: I opened an .fp5 file in a hex editor and found several occurrences of the hex code 0x1D, so I guess it's not a bad character in itself (unlike some people I could name). You might try looking for all the occurrences of that character in your file to see if you can trace it to something identifiable. I used ExamDiff in my trials, which gives me some ability to identify what the hex character actually represents in the Filemaker file, though I think there would still be a lot of guesswork.

I will not however, give up as I think finding the invalid character will prove a rewarding experience....

I think you are now into the realm of knowledge for knowledge's sake. Enjoy the ride.

[QuinTech]

Another thought -- maybe this is not a Filemaker problem or a data problem at all. I've seen my XML editor barf at certain characters which would be perfectly acceptable in other contexts. Could it be that the problem is not the output, but the way the output is handled by whatever XML processor is handling it?

Have you tried making the report HTML format? Also, try turning off "Automatically open report when done". Does that change anything?

[flook]

Hurray and at the same time what a dissapointment as I thought the answer was going to be groundbreaking (who am I fooling).

QuinTech, I took your approach as the thought of going through 76 layouts with 757 fields, slightly moving them and then going back into browse mode was bordering on an attempt at Satie's Vexations.

Funnilly enough it was exporting as an XML and not allowing it to launch that got me there as it then showed the beggining of the field calc that was causing a parsing error.

Probably should have exhausted every avenue before bothering the forum, but it was nice to get so much advice.

Time to get of the knowledge ride for a while and get out a bit more.

Thanks everyone.

[QuinTech]

LOL, a new phrase to describe programming hell -- Satie's Vexations! Thanks for that, flook.

Funnilly enough it was exporting as an XML and not allowing it to launch that got me there as it then showed the beggining of the field calc that was causing a parsing error.

So you're saying that exporting the DDR to HTML avoided the problem? Were you able to determine what 0x1D actually is? I'm curious now.

Probably should have exhausted every avenue before bothering the forum, but it was nice to get so much advice.

No bother at all. Some of us enjoy puzzlers like this. (What was that you said about needing to get out more? You could write a program that will maximize the amount of time you spend in recreation ... )

[Søren Dyhr]

I used ExamDiff in my trials, which gives me some ability to identify what the hex character actually represents in the Filemaker file, though I think there would still be a lot of guesswork.

Although it can be entertaining to examine, do you use it for concurent versioning?? Am I wrong in thinking that making a DDR is only an export, you can't regain an idea from earlier versions by by making changes to the XML and reimport it???

I know that it can be done to a certain extent ...but the desire to do so only occured resently. Corn Walker replied in the FMExperts list:

We use SVN to provide revision control for our FMP projects. Our development team is not so large that we need the locking features (aka reserved checkout) of the SVN 1.2 release but the feature is helpful for FMP files where potentially two or more users may modify the same file. SVN might not make sense for concurrent development of projects which involve only one or two files but it does make a lot of sense for versioning. Because SVN stores only the "changes" you make to a file, even binary files like FMP, you have much better space utilization. While I haven't had to yet, I could roll back to any revision from the very beginning of the project to just yesterday. I typically commit a revision three or four times each week and create a "build" once a major milestone has been reached. For example, on my current project I am on revision 121 and build 1A07 (the 121st revision to the project and the seventh milestone). Each time I commit a revision I type in a note to detail what changed in the revision. If I want to "undo" a change I can go back to the revision before I made the change

--sd

[flook]

I'm pretty certain that the offending character was a "Paragraph Constant" at the end of the calculation. I was using this in a calculation that exported a repeating fields information out of a database (the text being formatted first) and then imported back in starting at a different repeating field number (this was a theory I'd carried over from FP5 days) and thus was using simpletext not XML.

This calc, plus the repeating fields weren't even in use, I don't even use repeating fields (honest!). I was just trying out a number of theories etc, well you know how it is, the search for knowledge and all that.

Anyway!

So you're saying that exporting the DDR to HTML avoided the problem?

No, what I'm saying is that your idea made me think I've haven't tried doing that exporting as xml. Hey presto this way showed me the line and a reference to what the actual problem was.

As for Satie, if only he'd had access to a loop command on a piano he could still be going now (sorry Eric!).

[QuinTech]

do you use it for concurent versioning?

I have no idea -- I've never actually used a DDR. The file I was talking about examining was the actual Filemaker file, and not the DDR export.

It is probably absolute nonsense to look at a Filemaker file with a hex editor, but I was thinking that if it were some corrupt character, flook might be able to locate it in this way.

SVN sounds intriguing. Do you know if this is what he is talking about?

[Søren Dyhr]

SVN sounds intriguing. Do you know if this is what he is talking about?

There are actually 100's of tools out there to be investigated, but usually for lowlevel language developers... but filemakers drag'n'drop developement tools, makes them tough to make deep and radical rollback in.

I my resent case did a denomalized approach fit the bill better than the one by the book, so reinstating tables that I got rid of including fields def. and relationsships had to be made from scratch again.

So Corn says that some of it can be done ...unfortunately forces it me to learn a lot more about unix than I have thought I would need. Another intriguing fact that if you develope in teams and different ideas is tried, could be best of the approaches be filled into the surviving solution.

--sd

[flook]

Hi Soren

I wanted the DDR as a "snapshot" of the file at that point in it's development. I was starting to get the feeling that things were running away from me and felt this would offer a good fall back if any problems came up later. The handy thing about not being able to create the DDR is that it made me deal with these issues immediatley.