Hi all,
I have to duplicate something like 300 fileds in a table, for a total
of 600 fields.
The field defined so far have the following name:
Pluto_1 Pluto_2 Pluto_3...
is that possible in some way (script or something else) automatically
create the new fields so that they will have the followng name and
format:
New_Pluto_1 New_Pluto_2 New_Pluto_3...
Thank you in advance
Diego
In article <1187918957.600740.36030@x40g2000prg.googlegroups.com>,
Diego B
> Hi all,
>
> I have to duplicate something like 300 fileds in a table, for a total
> of 600 fields.
> The field defined so far have the following name:
>
> Pluto_1 Pluto_2 Pluto_3...
>
> is that possible in some way (script or something else) automatically
> create the new fields so that they will have the followng name and
> format:
>
> New_Pluto_1 New_Pluto_2 New_Pluto_3...
>
>
> Thank you in advance
>
> Diego
In FMP 8.5 and 9 you can copy a bunch of fields and paste them, thus
creating a duplicate set. The duplicates will have "2" after the field
name. Then you have to go through and rename them.
in FMP 7 and earlier, you can duplicate individual fields and then
rename the duplicate.
I don't think there is any script step for defining fields or renaming
fields.
I'm curious about your database structure that requires duplicating so
many fields. What are you trying to accomplish? There may be a more
efficient way.
--
For email, change
Bill Collins
> In FMP 8.5 and 9 you can copy a bunch of fields and paste them, thus
> creating a duplicate set. The duplicates will have "2" after the field
> name. Then you have to go through and rename them.
Maybe not the perfect solution, but not too bad !
Is that easy to create a duplicate set (I am just on FM 8.5 adv.
XP) ?
> I'm curious about your database structure that requires duplicating so
> many fields. What are you trying to accomplish? There may be a more
> efficient way.
I created this DB for clinical research purposes. So far
I have 350 records and a total of 400 variables (fields)
Although the DB has been extended in the last months,
to include data regarding clinical variables, biomarkers and
genetics,
its main purpose is storing information obtained from a
a new echocardiographic (imaging) technique that is name
" Strain Imaging", on patients with pretty rare heart diseases:
cardiomyopathies.
Strain can give you information about velocity displacement, strain
rate (velocity
of deformation) and strain itself (global deformation, in percentage)
for each of the
18 heart segments (conventionally defined) and in both systole
(contraction, one measurement per modality)
and diastole (relaxation, two measurements per modality).
To make the things even more complex, to date, there are two ways to
obtain the same measurements
(Doppler and Speckle strain) and both have to be collected for
pathophysiological and technical insights.
If you perform the obvious arithmetic, you see how easily you reach
300 variables (without considering
the composite variables obtained averaging clusters of segments, that
are calculated fields in FM).
Finally, I already defined all the required variables for the Doppler
Strain, but now I have to expand the DB to be ready
to collect also Speckle strain measures.
The names of the fields are essentially the same, something like:
Doppler_TVI_BasalLateral
where Doppler is the way used to obtain strain,
TVI is Tissue velocity imaging, nad Basal Lateral is
the specific semgnent. Now I have to add
Speckle_TVI_BasalLateral
etc...
If you read until this point, I think you are a cardiologist and
should come to work with me : )
Anyway, if you have a way to make the things simpler, please share !
Unfortunately, using so many fields slows FM down sensitively (only in
the Strain Table though), so if you have some tips
to make it faster, I would really appreciate.
Thank you for the advices...and for the curiosity (never be too
curious ; )
Diego
On 2007-08-24 09:25:17 -0700, Diego B
> If you read until this point, I think you are a cardiologist and
> should come to work with me : )
>
> Anyway, if you have a way to make the things simpler, please share !
>
> Unfortunately, using so many fields slows FM down sensitively (only in
> the Strain Table though), so if you have some tips
> to make it faster, I would really appreciate.
Well, I'm not a cardiologist, but I did have a heart attack and a
bypass operation last year, does that count?
If you're having problems with speed of display, having many calculated
fields on the screen is most likely the cause. Simply displaying 300
or 600 plain number fields will not cause slowness, but displaying
summary fields or calculations, particularly ones dependent on related
fields, will bring a db to its knees.
One solution is to enter all the base data, and then have a script that
contains the necessary calculations use Set Field to establish all the
calculated values. Those fields then become non-calculated number
fields and will display, sort, and summarize very quickly when
reporting or moving from record to record.
You can also do a great deal with auto-enter calculations in number
fields if you don't want to use a script. These also display quickly,
but sometimes need help triggering when new values are entered. In this
case the functions Let and Evaluate are your friends.
--
Lynn Allen
--
www.semiotics.com
562.938.7890
Member Filemaker Business Alliance
Long Beach, CA
> Well, I'm not a cardiologist, but I did have a heart attack and a
> bypass operation last year, does that count?
I am very sorry about that, did not intend joke in any way,
I apologize.
>
> If you're having problems with speed of display, having many calculated
> fields on the screen is most likely the cause. Simply displaying 300
> or 600 plain number fields will not cause slowness, but displaying
> summary fields or calculations, particularly ones dependent on related
> fields, will bring a db to its knees.
Actually there no that many calculated fields (no more than 40,
globally, maybe less,
do you think this could be the problem ?
I noticed that, when I use the tabs in the layouts FM slows down
noticeably.
I would avoid using Tabs, but there are so many fields in the Echo
Table that I am forced to
do that. Is this problem recognized somewhere or I am the first to
report it ?
>
> One solution is to enter all the base data, and then have a script that
> contains the necessary calculations use Set Field to establish all the
> calculated values. Those fields then become non-calculated number
> fields and will display, sort, and summarize very quickly when
> reporting or moving from record to record.
I like this idea, more than auto-enter option.
The script should be something like
set field:: Doppler_GlobalAverage
Insert calculated result:: Average (Basal_Lateral; Bas_InfSeptum;
Bas_InfLat etc...)
is that correct ?
>
> You can also do a great deal with auto-enter calculations in number
> fields if you don't want to use a script. These also display quickly,
> but sometimes need help triggering when new values are entered. In this
> case the functions Let and Evaluate are your friends.
I am not used to those functions but I am ready to get new friends : )
> --
> Lynn Allen
Thank you very much !
Diego
On 2007-08-24 12:36:12 -0700, Diego B
> Actually there no that many calculated fields (no more than 40,
> globally, maybe less,
> do you think this could be the problem ?
> I noticed that, when I use the tabs in the layouts FM slows down
> noticeably.
> I would avoid using Tabs, but there are so many fields in the Echo
> Table that I am forced to
> do that. Is this problem recognized somewhere or I am the first to
> report it ?
I suspect it's not the tabs it's the fields displayed on the tabs. Yes,
40 calculated fields could slow down a solution depending on how many
related fields they refer to or what the calculation is. No one else
has reported tabs as a performance drag.
>
> I like this idea, more than auto-enter option.
> The script should be something like
>
> set field:: Doppler_GlobalAverage
> Insert calculated result:: Average (Basal_Lateral; Bas_InfSeptum;
> Bas_InfLat etc...)
I would put the calculation directly in the Specify dialog of the Set
Field. Insert calculated result is redundant, and that script step
requires that the field be on the layout. Set Field does not.
And if you're using Average on screen, that's DEFINITELY the cause of
your slowdown. Every time you move from record to record, or from Tab
to Tab, every Average field that displays will have to re-evaluate in
order to display.
An average of values on the present record can easily be set by script
and be valid.
If your Average covers all records in the db, then every time you enter
a new record the average will change for all records, and this is not a
good candidate for scripted setting, because the values in all other
records will become invalid.
In that case, you'd need to restructure your db to only display average
or other summary fields on specific layouts or on reports, rather than
on live layouts where you enter data.
> --
Lynn Allen
--
www.semiotics.com
562.938.7890
Member Filemaker Business Alliance
Long Beach, CA
> An average of values on the present record can easily be set by script
> and be valid.
>
> If your Average covers all records in the db, then every time you enter
> a new record the average will change for all records, and this is not a
> good candidate for scripted setting, because the values in all other
> records will become invalid.
>
Fortunately the Averages (I defined different fields by different
clusters of segments)
involves only one table, not the whole DB.
> In that case, you'd need to restructure your db to only display average
> or other summary fields on specific layouts or on reports, rather than
> on live layouts where you enter data.> --
>
I will do that, as soon as I will have enough time !
> Lynn Allen
> --www.semiotics.com 562.938.7890
> Member Filemaker Business Alliance
> Long Beach, CA
Thank you so much, I really appreciate : )
Diego B wrote:
> Hi all,
>
> I have to duplicate something like 300 fileds in a table, for a total
> of 600 fields.
> The field defined so far have the following name:
>
> Pluto_1 Pluto_2 Pluto_3...
>
> is that possible in some way (script or something else) automatically
> create the new fields so that they will have the followng name and
> format:
>
> New_Pluto_1 New_Pluto_2 New_Pluto_3...
>
>
> Thank you in advance
>
> Diego
>
Hi Diego,
working as I have for several decades in medical research
(Neurosurgery...) and having seen as many research data acquisition
databases as I have, I have a strong suspicion that the database in
question is one big flat file, hence the desire to replicate fields.
If this is the case (i.e that you have a flat file), it is going to
become very limiting and very cumbersome. If you are part of an academic
institution, perhaps approach the mathematics department, they should be
able to point you to someone who knows and can help about relational
database structure.
regards
Chris Brown
> If this is the case (i.e that you have a flat file), it is going to
> become very limiting and very cumbersome. If you are part of an academic
> institution, perhaps approach the mathematics department, they should be
> able to point you to someone who knows and can help about relational
> database structure.
>
First of all, thank you for the suggestion, actually I tried to look
for an engineer
or a data analyst in the BioInformatics departement here. Unfortuntely
I was no lucky
and I could not find anyone working on relational DBs (it looks like
all the people here love
SAS, and they do not see anything else than a spreadsheet to store
data...).
Because of that, and because I really like to do everything by myself
when I can
I started studying relational DBs and FM specifically.
Now, the question: what is a flat file ? I am sorry for the basic
question but I really do not know.
The DB structure I implemented is something very well defined in many
clinical DBs I saw and asked about:
a central table with a primary natural key (the ID) and a surrogate
one (the clinical chart number, so that
I can talk with the clinical DBs here) where demographic information
about the patient is stored, and many other tables for the
examinations : Echocardiography,
genetics, biomarkers, clinical variables etc...
all the tables are related trough the primary Patient key (ID), then
each table has its own primary key, as a serial number.
If you think there is something wrong in this, please let me know, I
am ready to send you also the DB, or if you have
something you trust (preferably in FM) you could send me an empty DB
just to understand how to make it in the right way.
> regards
>
Cheers !
> Chris Brown- Hide quoted text -
Diego
On 2007-08-27 09:53:35 -0700, Diego B
> If you think there is something wrong in this, please let me know, I
> am ready to send you also the DB, or if you have
> something you trust (preferably in FM) you could send me an empty DB
> just to understand how to make it in the right way.
Your structure seems proper, from such brief description.
A flat file would be a table where all your patient information AND
their test result was held in one record. Every time the patient came
back, you would create a new record and have to re-enter the base
patient information, duplicating everything that was there. If the
patient had 10 visits or 10 tests in one visit, they'd have 10 records.
Flat files contain lots of information duplicated within the table.
Because of the large number of fields (300, doubled) I'm thinking that
what people don't understand is that there really ARE that many
different values returned from one type of test. You want to show both
types of test on one record, I presume because having this info all in
one place has value for your diagnoses.
It might be possible to have your two different cardiology tests as two
records in a cardiology-test table, IF and only if they both measure on
the same set of values, that is, if they are both basically the same.
If TestOne has NumberA and not NumberB, and Test2 does not have
NumberA, but has NumberB, then you're going to have bunches of empty
fields if you try this.
If, on the other hand, all of Test1 and Test2's parameters are similar
but different (for example, different measurements, different units),
then putting them both on one record for comparison purposes seems
correct.
We don't know your business as well as you do. Studying relational data
design will help you make your data structure better and more robust
and it seems like you're going in the right direction.
--
Lynn Allen
--
www.semiotics.com
562.938.7890
Member Filemaker Business Alliance
Long Beach, CA
Diego B wrote:
> I started studying relational DBs and FM specifically.
>
> Now, the question: what is a flat file ? I am sorry for the basic
> question but I really do not know.
>
> The DB structure I implemented is something very well defined in many
> clinical DBs I saw and asked about:
>
> a central table with a primary natural key (the ID) and a surrogate
> one (the clinical chart number, so that
> I can talk with the clinical DBs here) where demographic information
> about the patient is stored, and many other tables for the
> examinations : Echocardiography,
> genetics, biomarkers, clinical variables etc...
> all the tables are related trough the primary Patient key (ID), then
> each table has its own primary key, as a serial number.
>
> If you think there is something wrong in this, please let me know, I
> am ready to send you also the DB, or if you have
> something you trust (preferably in FM) you could send me an empty DB
> just to understand how to make it in the right way.
>
>> regards
>>
>
> Cheers !
>
>
>> Chris Brown- Hide quoted text -
>
> Diego
>
>
Hi Diego,
it appears that yo do have a relational structure from the tables you
outline, and as Lynn also observes. How el that is implemented is
impossible to guess, without looking at the file(s).
A flat file approach can also result within a single table. For
example, the Echocardiography table the keying would be something like:
patient_ID, EchoCard_ID, TestDate, and possibly TestLab_ID.
What I have often seen is that people will create a set of fields to
record the data for a test or visit, and then replicate all those fields
for each subsequent test or visit or follow-up. So if there are 100
fields to record the results at a test/visit, and the patient comes in
every year for twelve years, then the table will end up with 100 x 12
fields. I have seen this on numerous occasions (several instances had
reached 15 years). This is what I thought may be happening, when you
originally referred to duplicating 300 fields.
A way to handle this would be to have a table of Tests_Echocardiography
(Echo_ID, TestType_ID, TestDate, Patient_ID) related to a
EchocardiographyResults table containing the 300 fields as well as the
appropriate key fields.
regards
Chris
On Aug 27, 7:34 pm, Chris Brown
wrote:
> Diego B wrote:
> > I started studying relational DBs and FM specifically.
>
> > Now, the question: what is a flat file ? I am sorry for the basic
> > question but I really do not know.
>
> > The DB structure I implemented is something very well defined in many
> > clinical DBs I saw and asked about:
>
> > a central table with a primary natural key (the ID) and a surrogate
> > one (the clinical chart number, so that
> > I can talk with the clinical DBs here) where demographic information
> > about the patient is stored, and many other tables for the
> > examinations : Echocardiography,
> > genetics, biomarkers, clinical variables etc...
> > all the tables are related trough the primary Patient key (ID), then
> > each table has its own primary key, as a serial number.
>
> > If you think there is something wrong in this, please let me know, I
> > am ready to send you also the DB, or if you have
> > something you trust (preferably in FM) you could send me an empty DB
> > just to understand how to make it in the right way.
>
> >> regards
>
> > Cheers !
>
> >> Chris Brown- Hide quoted text -
>
> > Diego
>
> Hi Diego,
> it appears that yo do have a relational structure from the tables you
> outline, and as Lynn also observes. How el that is implemented is
> impossible to guess, without looking at the file(s).
Lynn and Chris, thank you very much for the support...now I know
I am going in the right direction and this makes me happy (I think
you can immagine how long time I spent designing and implementing
this DB, at the beginning I made so many mistakes...)
>
> A flat file approach can also result within a single table. For
> example, the Echocardiography table the keying would be something like:
> patient_ID, EchoCard_ID, TestDate, and possibly TestLab_ID.
>
Now it is clear, I saw many flat files too, in access for example,
but
I did not know the correct name : )
> What I have often seen is that people will create a set of fields to
> record the data for a test or visit, and then replicate all those fields
> for each subsequent test or visit or follow-up. So if there are 100
> fields to record the results at a test/visit, and the patient comes in
> every year for twelve years, then the table will end up with 100 x 12
> fields. I have seen this on numerous occasions (several instances had
> reached 15 years). This is what I thought may be happening, when you
> originally referred to duplicating 300 fields.
>
Ok, fortunately I did not even think to implement something like that
sometimes you recognize how much lucky you are only afterwards...
Regards and thank you again, I will take advantage of all the advices
I got
here and keep upgrading my DB to obtain the best performance !
Diego