I'd like to put data into a field in a record like this:

0.10.3.0.0

That is, any 5 numbers separated by full-stops

The idea of this is placeholders.

Example: "0.10.3.0.0" means:

zero 1xbed apartments
ten 2xbed apartments
three 3xbed apartments
zero 4xbed apartments
zero 5xbed apartments

In this case there are a total of 13 (10+3) apartments.

I'd like another field in each record to be able to convert the
placeholder info into a total number of units. What nifty Filemaker
function would do this ?

regards

marmot

PatternCount

If you use a fixed length, Left, Middle, and Right will also do.

For example, the Bedx2 = TextToNum( Middle( data; Position( data; ".";
1; 1) + 1;
Position( data; "."; 1; 2) - Position( data; "."; 1; 1) - 1))
Remi-Noel


"marmot" <thdyoung (AT) mac (DOT) com> a écrit ...

In article <1129655994.904426.46090 (AT) g44g2000cwa (DOT) googlegroups.com>,
thdyoung (AT) mac (DOT) com says...
Any particular reason? I mean why not spaces, commas, or semicolons?
Why not separate fields?

MiddleWords()

-regards,
Dave

What version? If FM8, you can do this:

GetValue(substitute(AptUnits, ".", "¶"), X)

where X is the value you'd like to extract (1-5). Add 'em all up or
whatever you want to do.

Not sure why you wouldn't separate them into different fields or, at the
very least, a repeating field. In that case, you can get the total with
sum(RepeatingField)



marmot wrote:
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg (818) 883-2846
FM Pro Solutions Los Angeles, California

FileMaker 7 Certified Developer
Associate Member, FileMaker Solutions Alliance

Hi
thanks for your reply Howard. I'm on fm7 unfortunately.

I could have used separate field but that's more fields and I had a
feeling they might get too numerous. If I can make this placeholder
thing work then in fact I can describe a whole mid-size building
development in one field.

A row of comma, period or space separated numbers all in one field
might well serve to describe all the apartments, maisonettes, houses,
workspaces and shops types in a development.

Understanding how to use functions PatternCount, MiddleWords, GetValue
etc is starting to look very much like the solution that I need.

regards

marmot

In article <1129664105.996975.270230 (AT) g49g2000cwa (DOT) googlegroups.com>,
thdyoung (AT) mac (DOT) com says...
It sure is.

Fields aren't some sort of precious resource. There are practical limits
of course, but if the only reason you are cramming 6 or 7 discrete
pieces of information into a single field is to preserve fields you are
working against the database instead of working with it.

Take step back for a moment, and consider what you are advocating.
Handling "rows of comma separated values" is what databases fields and
spreadsheet columns were invented for.

Deliberately encoding/parsing data into a comma separated values row
stored in a text field is like buying a fridge, using it to make ice
cubes, then taking all your food and packing it in a cardboard box with
the icecubes and sticking it in the fridge.

Sure you might do something like that the night before going camping,
and likewise there are times when sense to concatenate data in a single
field instead of storing it separately (e.g. maybe you need to export it
in some esoteric format for an existing system), but it just doesn't
make sense to design a database to store data like that.

Regards,
Dave

My database needs to store info about building development options
amongst other things. Each development can consist of apartments ,
maisonettes, houses, workspaces and shops. Many times, there'll be
several development options for a single site.

The vast majority of these possibilities will come to nought so I want
to be economic with time. I need, all the same, to track work done. It
could be useful later if it's databased appropriately.

If I have to store info about 1-5 bed configurations of apartments,
maisonettes, or houses, isn't that a total of 15 fields ? Instead of 15
fields, I can get all the info in three fields, or even one.

I got the idea for a field of this kind with placeholders from mucking
about with permissions in UNIX e.g ugo=rwx/777 etc

marmot

In article <1129671083.114777.148660 (AT) o13g2000cwo (DOT) googlegroups.com>,
thdyoung (AT) mac (DOT) com says...

Trust me, 15 fields isn't going to break filemaker. That said, I'm
beginning to think you need an entirely different approach. (see below)

If you try hard enough you can get the whole record into one field, or
even the whole database. That's hardly a goal worth striving for though
;D

It sounds to me like you need a -relational- model to handle this. Where
the "development options" that come to something are each in a related
record, while the options that come to nothing aren't stored.

e.g.

a table like "ProjectID, DwellingType, Quantity" related to your master
table. For each dwelling type there's a record. Projectid relates it
back to the project table, dwellingtype is a drop-down list of values
such as "1-Bedroom Apartment, 2-Bedroom Apartment, 1-Bedroom Maisonette,
Shop, etc etc).


E.g. Project1:
Related records:
Project1, 1-Room Apartments, 12
Project1, 2-Room Apartments, 14

Project2:
Related Records:
Project2, 1-Room Maisonettes, 18
Project2, 2-Room Maisonettes, 8
Project2, 3-Room Maisonettes, 5
Project2, Shops, 5
Project2, Workspaces, 2

And you could display this information in a portal.
I think its a much more natural way to organize this data.

For a project that uses 2 out of the 15 dwelling options you have two
related records. And if you have a large project that manages to use all
of them, that's ok too.

Its a "better" way of approaching the problem, one that leverages what a
relational database can do.

This is very helpful.