Very Computer

by **David Newco** » Sat, 12 Oct 2002 12:32:11

I have 2 databases related via a one-to-many relationship.

We have an ongoing problem whereby certain fields (whose input is
controlled by a value list) seemingly randomly change. But they always
change to another value on the value list.

Other fields sometimes change randomly, too. Strangely, a great many
fields NEVER change randomly.

And we NEVER see garbage characters in the changed field (which would
clearly indicate corruption).

I'm pretty sure it's not a rogue script...I modified every script that
modifies any field to write to an "audit trail" field what it's
changing. That turned up nothing.

We're almost certain it's not user error. When the data does change,
it changes from bold colored text (which the primary user of these
databases manually selects) back to black plain text. If a user
selected a different value frmo the value list by accident, it would
remain bold and colored. But that's never been the case...it's always
back to black plain text.

Has anyone ever seen filemaker "corrupted" so perfeclty and
consistently in some fields, but never others, with no garbage
characters, and only with values from the value list?

-- Dave

by **Michael Stou** » Sun, 13 Oct 2002 00:13:13

How are the Value List set up. Are they custom, from a field, from a
relationship. Are they on the Layout as a Related field or native.

What is the one-to-many relationship based on.

--
Michael Stout

http://www.fmpdev.com/

Quote:> I have 2 databases related via a one-to-many relationship.

> We have an ongoing problem whereby certain fields (whose input is
> controlled by a value list) seemingly randomly change. But they always
> change to another value on the value list.

> Other fields sometimes change randomly, too. Strangely, a great many
> fields NEVER change randomly.

> And we NEVER see garbage characters in the changed field (which would
> clearly indicate corruption).

> I'm pretty sure it's not a rogue script...I modified every script that
> modifies any field to write to an "audit trail" field what it's
> changing. That turned up nothing.

> We're almost certain it's not user error. When the data does change,
> it changes from bold colored text (which the primary user of these
> databases manually selects) back to black plain text. If a user
> selected a different value frmo the value list by accident, it would
> remain bold and colored. But that's never been the case...it's always
> back to black plain text.

> Has anyone ever seen filemaker "corrupted" so perfeclty and
> consistently in some fields, but never others, with no garbage
> characters, and only with values from the value list?

> -- Dave

by **David Newco** » Sun, 13 Oct 2002 11:47:06

They are custom, and they're on two layouts, one in each db. On one
db, it's on the layout as a related field, but the value list is
native to the db. On the other, it's the opposite...the field is
native to the db, but the value list is being pulled from the other
db...not sure why I did it this way, I'm sure I had a reason at the
time. i think I was doing some others this way and I wanted to keep it
consistent.

One-to-many relationship is based on a serially increasing 4-digit
number created/incremented by fmpro and auto-entered. A portal is also
on the main db, and that's how the "many" records are created...they
automatically are assigned the 4-digit number to link them to the main
db.

--D

> How are the Value List set up. Are they custom, from a field, from a
> relationship. Are they on the Layout as a Related field or native.

> What is the one-to-many relationship based on.

> --
> Michael Stout

> http://www.fmpdev.com/

> > I have 2 databases related via a one-to-many relationship.

> > We have an ongoing problem whereby certain fields (whose input is
> > controlled by a value list) seemingly randomly change. But they always
> > change to another value on the value list.

> > Other fields sometimes change randomly, too. Strangely, a great many
> > fields NEVER change randomly.

> > And we NEVER see garbage characters in the changed field (which would
> > clearly indicate corruption).

> > I'm pretty sure it's not a rogue script...I modified every script that
> > modifies any field to write to an "audit trail" field what it's
> > changing. That turned up nothing.

> > We're almost certain it's not user error. When the data does change,
> > it changes from bold colored text (which the primary user of these
> > databases manually selects) back to black plain text. If a user
> > selected a different value frmo the value list by accident, it would
> > remain bold and colored. But that's never been the case...it's always
> > back to black plain text.

> > Has anyone ever seen filemaker "corrupted" so perfeclty and
> > consistently in some fields, but never others, with no garbage
> > characters, and only with values from the value list?

> > -- Dave

by **Michael Stou** » Sun, 13 Oct 2002 13:13:31

I would take another look at your scripts. One of them must be affecting
these fields.

My first thought was that you might be using these field in a relationship.
One additional thought if someone deletes a record that the Value List is
getting info from what would happen.
-Michael

> They are custom, and they're on two layouts, one in each db. On one
> db, it's on the layout as a related field, but the value list is
> native to the db. On the other, it's the opposite...the field is
> native to the db, but the value list is being pulled from the other
> db...not sure why I did it this way, I'm sure I had a reason at the
> time. i think I was doing some others this way and I wanted to keep it
> consistent.

> One-to-many relationship is based on a serially increasing 4-digit
> number created/incremented by fmpro and auto-entered. A portal is also
> on the main db, and that's how the "many" records are created...they
> automatically are assigned the 4-digit number to link them to the main
> db.

> --D

>> How are the Value List set up. Are they custom, from a field, from a
>> relationship. Are they on the Layout as a Related field or native.

>> What is the one-to-many relationship based on.

>> --
>> Michael Stout

>> http://www.fmpdev.com/

>>> I have 2 databases related via a one-to-many relationship.

>>> We have an ongoing problem whereby certain fields (whose input is
>>> controlled by a value list) seemingly randomly change. But they always
>>> change to another value on the value list.

>>> Other fields sometimes change randomly, too. Strangely, a great many
>>> fields NEVER change randomly.

>>> And we NEVER see garbage characters in the changed field (which would
>>> clearly indicate corruption).

>>> I'm pretty sure it's not a rogue script...I modified every script that
>>> modifies any field to write to an "audit trail" field what it's
>>> changing. That turned up nothing.

>>> We're almost certain it's not user error. When the data does change,
>>> it changes from bold colored text (which the primary user of these
>>> databases manually selects) back to black plain text. If a user
>>> selected a different value frmo the value list by accident, it would
>>> remain bold and colored. But that's never been the case...it's always
>>> back to black plain text.

>>> Has anyone ever seen filemaker "corrupted" so perfeclty and
>>> consistently in some fields, but never others, with no garbage
>>> characters, and only with values from the value list?

>>> -- Dave

by **Greg Dembe** » Mon, 14 Oct 2002 00:02:09

Are the fields that change sometimes defined as "Look-ups"?a

>They are custom, and they're on two layouts, one in each db. On one
>db, it's on the layout as a related field, but the value list is
>native to the db. On the other, it's the opposite...the field is
>native to the db, but the value list is being pulled from the other
>db...not sure why I did it this way, I'm sure I had a reason at the
>time. i think I was doing some others this way and I wanted to keep it
>consistent.

>One-to-many relationship is based on a serially increasing 4-digit
>number created/incremented by fmpro and auto-entered. A portal is also
>on the main db, and that's how the "many" records are created...they
>automatically are assigned the 4-digit number to link them to the main
>db.

>--D

- Show quoted text -

>> How are the Value List set up. Are they custom, from a field, from a
>> relationship. Are they on the Layout as a Related field or native.

>> What is the one-to-many relationship based on.

>> --
>> Michael Stout

>> http://www.fmpdev.com/

>> > I have 2 databases related via a one-to-many relationship.

>> > We have an ongoing problem whereby certain fields (whose input is
>> > controlled by a value list) seemingly randomly change. But they always
>> > change to another value on the value list.

>> > Other fields sometimes change randomly, too. Strangely, a great many
>> > fields NEVER change randomly.

>> > And we NEVER see garbage characters in the changed field (which would
>> > clearly indicate corruption).

>> > I'm pretty sure it's not a rogue script...I modified every script that
>> > modifies any field to write to an "audit trail" field what it's
>> > changing. That turned up nothing.

>> > We're almost certain it's not user error. When the data does change,
>> > it changes from bold colored text (which the primary user of these
>> > databases manually selects) back to black plain text. If a user
>> > selected a different value frmo the value list by accident, it would
>> > remain bold and colored. But that's never been the case...it's always
>> > back to black plain text.

>> > Has anyone ever seen filemaker "corrupted" so perfeclty and
>> > consistently in some fields, but never others, with no garbage
>> > characters, and only with values from the value list?

>> > -- Dave

--

by » Mon, 14 Oct 2002 22:07:54

As the Text format is changing I would think it's a 'paste' step somewhere,
maybe another script, or even the user, is using the clipboard.

> Are the fields that change sometimes defined as "Look-ups"?a

> >They are custom, and they're on two layouts, one in each db. On one
> >db, it's on the layout as a related field, but the value list is
> >native to the db. On the other, it's the opposite...the field is
> >native to the db, but the value list is being pulled from the other
> >db...not sure why I did it this way, I'm sure I had a reason at the
> >time. i think I was doing some others this way and I wanted to keep it
> >consistent.

> >One-to-many relationship is based on a serially increasing 4-digit
> >number created/incremented by fmpro and auto-entered. A portal is also
> >on the main db, and that's how the "many" records are created...they
> >automatically are assigned the 4-digit number to link them to the main
> >db.

> >--D

> >> How are the Value List set up. Are they custom, from a field, from a
> >> relationship. Are they on the Layout as a Related field or native.

> >> What is the one-to-many relationship based on.

> >> --
> >> Michael Stout

> >> http://www.fmpdev.com/

> >> > I have 2 databases related via a one-to-many relationship.

> >> > We have an ongoing problem whereby certain fields (whose input is
> >> > controlled by a value list) seemingly randomly change. But they
always
> >> > change to another value on the value list.

> >> > Other fields sometimes change randomly, too. Strangely, a great many
> >> > fields NEVER change randomly.

> >> > And we NEVER see garbage characters in the changed field (which would
> >> > clearly indicate corruption).

> >> > I'm pretty sure it's not a rogue script...I modified every script
that
> >> > modifies any field to write to an "audit trail" field what it's
> >> > changing. That turned up nothing.

> >> > We're almost certain it's not user error. When the data does change,
> >> > it changes from bold colored text (which the primary user of these
> >> > databases manually selects) back to black plain text. If a user
> >> > selected a different value frmo the value list by accident, it would
> >> > remain bold and colored. But that's never been the case...it's always
> >> > back to black plain text.

> >> > Has anyone ever seen filemaker "corrupted" so perfeclty and
> >> > consistently in some fields, but never others, with no garbage
> >> > characters, and only with values from the value list?

> >> > -- Dave

> --

by **David Newco** » Tue, 15 Oct 2002 07:06:28

They are not. They are defined as follows: Index, Auto-Enter, By value
list, Strict, Required value.

I have a lot of scripts that perform searches where I set the field
(in find mode) to "Cancelled" -- precisely what shows up from time to
time in this rogue fashion. But I went over every script and it's
always in find mode first...could this be a factor somehow?
corruption? We've been backing up the databases without exiting (which
we just found out is a bad thing)...they're being served by fmpro 5.5
server under OS X.

> Are the fields that change sometimes defined as "Look-ups"?a

> >They are custom, and they're on two layouts, one in each db. On one
> >db, it's on the layout as a related field, but the value list is
> >native to the db. On the other, it's the opposite...the field is
> >native to the db, but the value list is being pulled from the other
> >db...not sure why I did it this way, I'm sure I had a reason at the
> >time. i think I was doing some others this way and I wanted to keep it
> >consistent.

> >One-to-many relationship is based on a serially increasing 4-digit
> >number created/incremented by fmpro and auto-entered. A portal is also
> >on the main db, and that's how the "many" records are created...they
> >automatically are assigned the 4-digit number to link them to the main
> >db.

> >--D

> >> How are the Value List set up. Are they custom, from a field, from a
> >> relationship. Are they on the Layout as a Related field or native.

> >> What is the one-to-many relationship based on.

> >> --
> >> Michael Stout

> >> http://www.fmpdev.com/

> >> > I have 2 databases related via a one-to-many relationship.

> >> > We have an ongoing problem whereby certain fields (whose input is
> >> > controlled by a value list) seemingly randomly change. But they always
> >> > change to another value on the value list.

> >> > Other fields sometimes change randomly, too. Strangely, a great many
> >> > fields NEVER change randomly.

> >> > And we NEVER see garbage characters in the changed field (which would
> >> > clearly indicate corruption).

> >> > I'm pretty sure it's not a rogue script...I modified every script that
> >> > modifies any field to write to an "audit trail" field what it's
> >> > changing. That turned up nothing.

> >> > We're almost certain it's not user error. When the data does change,
> >> > it changes from bold colored text (which the primary user of these
> >> > databases manually selects) back to black plain text. If a user
> >> > selected a different value frmo the value list by accident, it would
> >> > remain bold and colored. But that's never been the case...it's always
> >> > back to black plain text.

> >> > Has anyone ever seen filemaker "corrupted" so perfeclty and
> >> > consistently in some fields, but never others, with no garbage
> >> > characters, and only with values from the value list?

> >> > -- Dave

> --

by **David Newco** » Tue, 15 Oct 2002 07:12:49

Michael, can you clarify...what do you mean if someone deletes a
record that the value list is getting info from what would happen?

-- Dave

> I would take another look at your scripts. One of them must be affecting
> these fields.

> My first thought was that you might be using these field in a relationship.
> One additional thought if someone deletes a record that the Value List is
> getting info from what would happen.
> -Michael

by **Michael Stou** » Tue, 15 Oct 2002 08:16:02

This was a question prior to you explaining how the value list was set up.
My thought was if the value list was based on a field (not a custom list)
that when that record was deleted the field value would change.

Without being able to look at all the different things that could be
affecting the fields, It like shooting in the dark.

Take another look at the fields that are randomly changing. Make sure they
are not based on a dynamic relationship. That they only have access to these
fields via the value list and that the proper relationship is being used for
the one that in on the layout as a related field.

Make sure the field is not a global and that there is only one instance each
of these fields.

Oh yea and good luck. It is most likely something real simple or obvious
once you track it down.

Take care,

--
Michael Stout

http://www.fmpdev.com/

> Michael, can you clarify...what do you mean if someone deletes a
> record that the value list is getting info from what would happen?

> -- Dave

>> I would take another look at your scripts. One of them must be affecting
>> these fields.

>> My first thought was that you might be using these field in a relationship.
>> One additional thought if someone deletes a record that the Value List is
>> getting info from what would happen.
>> -Michael

Very Computer

Wierd corruption that fits a "pattern"?

Wierd corruption that fits a "pattern"?

Wierd corruption that fits a "pattern"?

Wierd corruption that fits a "pattern"?

Wierd corruption that fits a "pattern"?

Wierd corruption that fits a "pattern"?

Wierd corruption that fits a "pattern"?

Wierd corruption that fits a "pattern"?

Wierd corruption that fits a "pattern"?

Wierd corruption that fits a "pattern"?