FileMaker is more than happy to set users up with “value lists,” which coyly store multiple values in a field — a concept that’s pretty much anathema to “real” databases. Values in the list are separated by a weird ascii character. To forge a bridge b/w MySQL and FileMaker, wrote a routine to grab each element in a form array and insert this weird character between each. If all elements were named perfectly, FM would show the proper boxes checked upon data import. In a prior incarnation of this system, data was output from MySQL to a web page, then imported into FM. But now that this weird ascii character is present, we were getting inconsistent results. After much sleuthing, turned out that some browsers (Make 7 Up Yours, IE/Mac) were conveniently discarding the special character, so nothing matched on import. Rewrote the app to write the export to a text file on the server, the offer the file for download, taking browser discrepancies out of the mix.
High ASCII Madness
Music: Black Cat Orchestra :: Sanfonando
3 Replies to “High ASCII Madness”
Reason #467,082 to use a Real (ie, relational) database instead of FileBreaker. Relational became state of the art in what, 1970? I have no idea why these flat-file dbs hang on, but they do.
Anyway, I sometimes store multiple values in a field, but only if I know they are always going to be integer or char. Occasionally useful to save development time. Would never give a user direct edit access to the field, tho, because some jerk will eventually enter the character you use to separate ’em.
Man, no kidding. Although I can see why it’s still so popular – there’s no easier database to set up and use for a standard office type person. FileBreaker (LOL!) does have a minimal/weird sense of relationality — you set up multiple databases (each of which is essentially a flat file table in disguise) and make them aware of one another. Weird.
Fortunately I’ve got the folks pretty much sold on moving on from FM to MySQL. Unfortunately they’re # 478 in the to-do queue, so this solution will have to do for now.
Non-relational DBMS have advantages if your DB problem doesn’t require the full power of a RDBMS – they are conceptually simpler and can be implemented with less space and time.
Of course if the problem moves from the non-R into the R problem space, the proper solution is to implement a RDBMS, not to add a gazillion bandaids to the non-RDBMS.