I need a script that when activated will create 12 new records and populate a qty field with a number that is not the same in the indivdual records, but is the same each time the script is called.

............QTY

Record1.......6

Record2......12

Record3......36

Record4......72

Record5.....144 etc, etc.

............QTY

Record6.......6

Record7......12

Record8......36

Record9......72

Record10.....144 etc, etc.

It would be a bonus if the user could predetermine with a related preference file what that "qty" number will be for each of the 12 newly created and populated records.

Any ideas would be greatly appreciated.

Thanks,

Steve

Create12.zip

Edited April 14, 200718 yr by Guest
reverted subject

How about something simple like this? Was this what you were looking for?

Create12.zip

Thanks for the help! I think we came up with almost identical solutions...But here is my latest quandary....

When those 12 records get created I also want them to have a unique identifier so I can perform a find based on that identifier and display only the those 12 results separately (in list view) from all of the other records in the DB.

I have been awake for the past 28 of 30 hours so I am probably missing something simple, but do you have any ideas?

What I need is a fourth field in your result example that has a unique word or number string in it for the records just created.

............QTY

Record1.......6...qt432

Record2......12...qt432

Record3......36...qt432

Record4......72...qt432

Record5.....144...qt432 etc, etc.

............QTY

Record6.......6...qt433

Record7......12...qt433

Record8......36...qt433

Record9......72...qt433

Record10.....144..qt433 etc, etc.

Thanks in advance for any help.

Steve

Edited April 14, 200718 yr by Guest

How about something simple like this? Was this what you were looking for?

I don't get this why two autoenter values, which as a consequence stores redundant info, provided the context are the second autoenter just an incarnation of the first.

Next issue is, shouldn't price a matrix benefit from the lookup next higher/lower in order to be as swift as posible??

--sd

I don't get this why two autoenter values, which as a consequence stores redundant info, provided the context are the second autoenter just an incarnation of the first.

Indeed this was from the Baylah's orig file. Autoentry in not needed here of course.

Next issue is, shouldn't price a matrix benefit from the lookup next higher/lower in order to be as swift as posible??

I am not sure what you mean. This wasnt a price matrix and IMO an import is the fastest way to duplicate a set of records from one table into another.

Edited April 14, 200718 yr by Guest

Try this

Create12.zip

Mr Vodka.....

Would you like that Martini shaken or stirred?

Thank you very much. I was not aware I could do this:

Name:$nextset

Value::Max ( test 2::Set ) + 1

Repetition::1

Your help is very much appreciated, this is exactly what I needed and lets me move move forward with a much larger project.

Steve

SD Writes <>

SD, There might be, probably is a better or different way to accomplish what I am trying to do here, but in the big picture Mr. Vodka has provided me an elegant and simple solution that does exactly what I need it.

It would be very difficult to explain why but if you would like I will post the full file I am using this in and you can offer your suggestions as to a better solution.

Thanks again to this amazing forum for helping out.

Steve

Dam* IT!

I can't get this to work in my solution I keep getting an error saying that it can't complete the script because a required table is missing.

I can't seem to get this and I am throwing myself on your mercy.

My guess is that the problem lies in the portion of the script that imports the records. I was not sure what file to assign here.

I hope I can dip from the knowledge trough again.

Thanks guys,

Steve

I have attached the full file here to see if someone can help me fiure out where I have gone wrong.

I have collapsed all of the tables in the relationship dialog except the ones in question. Everything else in this solution works except for this.

I have had to strip out all of the graphics to make the file fit here so it is not pretty, and I ahve yet to clean it up because it is still in development.

Create12.zip

One other thing....

Mr. Vodka,

In your solution the relation between qtybreaks_template and test is

one to many on the pkline::fkline relationship.

On the relationship that adds the new functionality

test::test 2

the fkLine::fkLine is a many to many relationship.

How is it possible in the first relationship that a one to many relationship exists when fkLine is not defined to be a unique value? And how is it possible that in a seperate realtionship using the same field it shows as a manny to many relationship?

I have so much to learn!

Steve

In your solution the relation between qtybreaks_template and test is

one to many on the pkline::fkline relationship.

On the relationship that adds the new functionality

test::test 2

the fkLine::fkLine is a many to many relationship.

How is it possible in the first relationship that a one to many relationship exists when fkLine is not defined to be a unique value? And how is it possible that in a seperate realtionship using the same field it shows as a manny to many relationship?

Sigh I guess I really should have done a better job cleaning up the orig sample file from you. I just decided to leave as much in there untouched as possible.

Ok. The first relationship is not needed for this example to work at all. On the test table, you should rename fkLine# to pkLineID because it is a serial primary key.

As for the second relationship, it is not a many to many per se. It is a cartesian join 'X' operator. This means that every record in the first TO is related to the every record of the second TO. Previous to FM7, developers used to use a simple calc field with a value of just 1. Since every record would then utlimately have a value of 1 for this field, this field was used as a key when joining to another table with a similar calc. Then every record from table A would be related to table B and viceversa when the relationships were created between those two fields. Luckily we do not have to add those steps now. In your case, it is a self join to the same table but it works the same.

I cant open your file because its locked but my guess would be that you did not rename the file name for the import. You will have to point it to your file supercalc... and map the import fields accordingly as well.

I'm sorry, the account and password are both admin. I can't believe I forgot to list that. Geesh!

Steve

I understand what is going on, I jsut can;t seem to get it to work!

Arghhhhh!

Steve

Edited April 15, 200718 yr by Guest

HIP HIP HOORAY! I FINALLY GOT IT! Everything is working!

Oh my gosh! That was an exercise in applying what I understood needed to happen but unable to get the mechanics (in this case syntax) proper.

Thanks For all of the help! I'm sure I will be back.

Edited April 15, 200718 yr by Guest