(Wow, I sure post a lot of 'find' problems... I wish I would 'get it')

Here is another one.

I have a table called Members

It has these fields: PK_TypeID, Type

I need to go into Members and 'find' an 'old value' ($$OldType) and then replace it with $$NewType.

Here is what happens.

I open a window

I put a layout that shows the Members table in the window.

I run script code that does this:

Enter Find Mode

Set field [Members::Type "="&$$OldType

(I can see =Regular entered into theType field)

Perform Find[]

I run debug and watch as everything works until I get to Perform Find[] which finds nothing. I can see the get(foundcount)=0

And, Find and Replace in a script also finds NOTHING!?

What am I doing wrong???

Thanks for reading...

Ron

Wrong syntax in the Set Field step:

Set field [Members::Type; $$OldType]

Wrong syntax in the Set Field step:

Set field [Members::Type; $$OldType]

I changed the Set field to $$OldType and the get(foundcount) is still (zero).

I am at a loss as to why this is happening.... Any other ideas?

Thanks

Update: It seems like my $$OldType is left padded with about 7 spaces.. huh? And, when I run debug

and delete the spaces, Find works.

So, in the Set Field script step I say Set Field; Type to Trim($$OldType). Wouldn't you think that would do it?

Well, it doesn't... grrrrrrrr.....

===================

FM trim() won't work for reasons I don't get. But, BrianDunning.com's SuperTrim did the job. Now find works!!!!

"I have a table called Members

It has these fields: PK_TypeID, Type"

Why would a table called "Members" have a primary key named for a Type? Its primary key should be MemberID (or __kP_MemID) and it should have a foreign key of _kF_TypeID. Although, if there can be more than one Type, perhaps over time, then you need a join table MemType.

Every time I read your posts, I question your structure.

"I have a table called Members

It has these fields: PK_TypeID, Type"

Why would a table called "Members" have a primary key named for a Type? Its primary key should be MemberID (or __kP_MemID) and it should have a foreign key of _kF_TypeID. Although, if there can be more than one Type, perhaps over time, then you need a join table MemType.

Every time I read your posts, I question your structure.

Oops. I should have said the Members table has fields of : PK_MemberID and Type.

When do you set $$OldType?

Also, why are you using a global $$var?

How about posting the script? Print it to PDF.

When do you set $$OldType?

Also, why are you using a global $$var?

How about posting the script? Print it to PDF.

The script is still in 'rough' format, but I hope it gives you an idea of what I am trying to do.

ReplaceMemberTypeCode.pdf

Your comments and criticisms are welcome and appreciated.

Ron

Remember, $vars live for the life of the script. $$vars live for the life of the session or until they are set to empty. Since you are staying in one script for the entire operation, you do not need $$vars. However, Since you've established global fields (gReplaceOLD and gReplaceNew) you don't need any $$vars or $vars. The values are in the globals.

So now, what value lists are you using to populate the globals and are they truly set to global storage (many of us add the "g" but don't set the storage)?

You don't need $$Kount, either.

BTW, Replace is NOT multi-user friendly. If one of your member records are in use, it will be skipped -- without any error thrown. If it matters that all records are updated or none at all, then this should be a transaction.

And finally, why don't you have IDs for Type!?

Remember, $vars live for the life of the script. $$vars live for the life of the session or until they are set to empty. Since you are staying in one script for the entire operation, you do not need $$vars. However, Since you've established global fields (gReplaceOLD and gReplaceNew) you don't need any $$vars or $vars. The values are in the globals.

So now, what value lists are you using to populate the globals and are they truly set to global storage (many of us add the "g" but don't set the storage)?

You don't need $$Kount, either.

BTW, Replace is NOT multi-user friendly. If one of your member records are in use, it will be skipped -- without any error thrown. If it matters that all records are updated or none at all, then this should be a transaction.

And finally, why don't you have IDs for Type!?

The posted script is one called by a script that loads a layout that askes the user to provide gOldType and gNewType.

After that, this 1st script, calls the script in the PDF.

I make all variables global becAUSE I want the variable to persist as I sometimes debug just the 2nd script without running the 1st script. Make sense? After it 'works' , I go back and change them to local variables.

I use $$Kount in a dialog explaing how many found records had been replaced. As in: "I replaced 24 records".

There are PK_TYPEID fields, I just didn't list them. I don't really use them.

Thanks for the critique and observation. I find it really useful to look at what I do through a more experienced, different set of eyes.

Ron

Ron, "...what value lists are you using to populate the globals and are they truly set to global storage (many of us add the "g" but don't set the storage)?"