At a loss...

[tedp58]

I have virtually zero experience with Scriptmaker, and have tried many times over the last 8 months to fix this. Hopefully a no-brainer for many of you. I don't know if it broke somehow, or if I did something to break this, but it worked for many years just fine. Someone else created the original files for me in version 4, I believe. Converted long ago to v9 Advanced.

[Ocean West]

How did it work previously? Can you elaborate what the "issue" that you are seeing now?

[comment]

I am guessing that the part after Sort Records[] should be:

Enter Preview Mode [Pause]

# or perhaps Print[]?

Go to Layout [original layout]

Enter Browse Mode[]

[tedp58]

Thanks for replying. I should have been more clear.

It's used in my "monthly summary" layout. It is used to display my orders for current month. For some reason, when I click the button to run the script, it displays everything starting in early March through current day.

One other problem is that, when viewing my monthly summary layout, it doesn't pull up records that were created as a result of duplicating a previous record, then changing various fields within the record.

Sorry for not having enough detail first time around. Lemme know if you need more.

Thanks again,

Ted

Edit: Here's something that probably means something: I have a script called "previous month" that brings up the records for the previous month. Running the script brings up February's orders. Something seems to think it's still March. ??

Edited November 7, 2008 by Guest

[comment]

Your script performs a find with stored criteria (which we cannot see in the picture). Stored criteria cannot be dynamic, so most likely your script always looks for records later than March 1, 2008, or similar. You need to switch to a calculated find, in the form of:

Enter Find Mode[]

Set Field [ some field ; ]

...

Perform Find[]

[IdealData]

I notice there is a

Perform Find [Restore]

This means that a find request is executed using a STORED set of criteria.

1. Create a duplicate script

2. Edit the duplicate script and remove the Perform Find. Save the script

3. Manually find the records you need

4. Run the duplicate script

All of this should give you a clue about the criteria you need to store in the script if you want to continue that way, but my instructions will work every time and your reporting need not be limited to the current month, instead it can be any range of dates.

[tedp58]

Does it help to know that this is the page that the script "brings up", with what should be the current month's records? It brings up this layout, but gives me all records since early March. It "sort of" works, just has the dates mixed up.

While I appreciate the help, I'm not catching on to the two suggestions. IdealData, I did try what you said. I ran the duplicate script, and it worked, once. After that one time it brought up only November's records, it reverted back to the "from March on" thing... I'm not sure I know what you mean after step 4 in your instructions above.

Thanks again, folks. If I can get this fixed, it'll make my week. If I could afford it, I'd just pay you to fix it. Unfortunately...

[Mark Welch]

I'm having a similar problem with 'find' -- I am trying to retrieve a specific record from a table by searching for its ID value (which is stored in a variable), but it appears that the variable is not being evaluated. Indeed, looking at the actual code (below), I see quotation marks -- but I cannot find any way to remove the quotation marks, as they are automatically inserted into the 'criteria.' There certainly MUST be a way to execute a search and retrieve a record whose field matches a variable -- but I cannot find it.

Enter Find Mode [ Specified Find Requests: Find Records; Criteria: movie_ids::movie_id: “$$_movie_id” ]

I have been pounding my head against this wall for many hours now.

Edited November 9, 2008 by Guest

[comment]

It is a similar problem, and the answer is the same as the one given earlier: stored criteria cannot be dynamic. Instead of:

Enter Find Mode [ Restore ]

Perform Find []

Do:

Enter Find Mode []

Set Field [ movie_ids::movie_id ; $$_movie_id ]

Perform Find []

[Mark Welch]

Thanks!

[Mark Welch]

OK, now I have a strange problem: I decided to rename one of my tables. Alas, ScriptMaker still refers to the table by its old name. I even tried "recover" to see if that would clean anything up, but it didn't. I now have a script that refers to the old name of the database.

Is there a way that I can properly rename my tables and fields without creating this type of problem?

I'm actually looking at the definite possibility that I should create a completely new database from scratch, and re-write the script (which seems likely to be a huge headache, since I can find no way to copy a script, and even if I could, I'd worry that it would just propegate the wrongly-named table into the new database).

[comment]

I decided to rename one of my tables. Alas, ScriptMaker still refers to the table by its old name.

That doesn't seem very likely. However, changing a table's name does not necessarily change the name/s of the table's occurrence/s in the relationships graph - and that is what you would see in ScriptMaker.

[Vaughan]

Hard-coded references to table names (or more accurately, TO names) won't get automatically updated when the TO is renamed.

Which is a good reason not to hard-code things like TO names.

When you say "rename a table" do you really mean renaming a file?

[comment]

How do you hard-code a TO name?

[Mark Welch]

I'd love an alternative to hard-coding table (and field) names -- but I don't understand how I could do this without hard-coding it.

What is apparently very important is the concept of a "layout" as distinct from a "table." Since FileMaker automatically created a layout for each table, I didn't realize that there was an extra "layer." Thus, changes to table names in the database don't propegate to the "layouts," which are "broken" since their corresponding table sources can't be found. Apparently there can be "layouts" that don't correspond directly to a specific table. It appears that only FileMaker can create "layouts" as distinct from reports, while I am relegated to creating layouts that are "reports."

Another issue for me is that there seem to be significant differences between layouts that are auto-created by FileMaker when a new table is created, compared to layouts that I create, which look different (visually). I'm reluctant to try coding anything that uses a "layout" that wasn't auto-generated by FileMaker.

I spent considerable time over the past year trying to learn current "vocabulary" and strategies for databases, but FileMaker is functionally very different from SQL Server or MySQL, and the new vocabulary and "forced" scripting system is confusing for me. (It's certainly easier to get started, and hopefully I can move forward with my "proof of concept" and then pay to have someone re-code it for MySQL or SQL Server.

The FileMaker documentation is very superficial, and because it also uses different vocabulary than I am used to, searching doesn't help very much.

So, some questions, if anyone can help:

(1) Is there a way to save a script as a text file? I've had to resort to "printing" from ScriptMaker and then using a PDF print driver to create a PDF.

(2) Where can I learn more about how "layouts" function in FileMaker, and how to make new "layouts" look like the ones that FileMaker generates itself? Also, where should I go to understand the concept of "graphs" to create and visualize the relationships between tables?

(3) I have absolutely no idea how to bring data from multiple tables together into a single view or layout (I suppose it's helpful that I now know several techniques that don't work). Each time I try, it LOOKS as if all the fields are there, but there is actually no data at all in the layout.

Edited November 9, 2008 by Guest

[Vaughan]

Sorry to say this bluntly: I'm not sure what you're doing, but it's not right. FMP should just work. It's much easier than you're making it.

"Thus, changes to table names in the database don't propegate to the "layouts," which are "broken" since their corresponding table sources can't be found."

No, that's not true at all. The only way a layout loses it's TO is if the TO is deleted from the relationship graph. Creating another TO with the same name doesn't re-link it back to the previously associated layouts. However it's easy (if a lot of work) to re-associate the layout (and fields on it) to another TO.

Think twice before deleting TOs.

"Another issue for me is that there seem to be significant differences between layouts that are auto-created by FileMaker when a new table is created, compared to layouts that I create, which look different (visually). I'm reluctant to try coding anything that uses a "layout" that wasn't auto-generated by FileMaker."

There is no difference between the layouts initially created by FMP and any others. Visually, the auto-created layouts use the default formatting settings, whatever these may be at the time the layout was created. The layout in my solutions look nothing like those initially created, and often one table may need several layouts, so limiting a solution to "auto-generated" layouts is not possible nor necessary.

"I spent considerable time over the past year trying to learn current "vocabulary" and strategies for databases, but FileMaker is functionally very different from SQL Server or MySQL, and the new vocabulary and "forced" scripting system is confusing for me."

General relational theory is as applicable to FMP as it is to MySQL -- stuff like normalisation and so on. Anything that starts getting into specific SQL functions is obviously not "general database theory" so it won't be applicable to FMP.

[bruceR]

I'd love an alternative to hard-coding table (and field) names -- but I don't understand how I could do this without hard-coding it.

What is apparently very important is the concept of a "layout" as distinct from a "table." Since FileMaker automatically created a layout for each table, I didn't realize that there was an extra "layer." Thus, changes to table names in the database don't propegate to the "layouts," which are "broken" since their corresponding table sources can't be found. Apparently there can be "layouts" that don't correspond directly to a specific table. It appears that only FileMaker can create "layouts" as distinct from reports, while I am relegated to creating layouts that are "reports."

Another issue for me is that there seem to be significant differences between layouts that are auto-created by FileMaker when a new table is created, compared to layouts that I create, which look different (visually). I'm reluctant to try coding anything that uses a "layout" that wasn't auto-generated by FileMaker.

I spent considerable time over the past year trying to learn current "vocabulary" and strategies for databases, but FileMaker is functionally very different from SQL Server or MySQL, and the new vocabulary and "forced" scripting system is confusing for me. (It's certainly easier to get started, and hopefully I can move forward with my "proof of concept" and then pay to have someone re-code it for MySQL or SQL Server.

The FileMaker documentation is very superficial, and because it also uses different vocabulary than I am used to, searching doesn't help very much.

So, some questions, if anyone can help:

(1) Is there a way to save a script as a text file? I've had to resort to "printing" from ScriptMaker and then using a PDF print driver to create a PDF.

(2) Where can I learn more about how "layouts" function in FileMaker, and how to make new "layouts" look like the ones that FileMaker generates itself? Also, where should I go to understand the concept of "graphs" to create and visualize the relationships between tables?

(3) I have absolutely no idea how to bring data from multiple tables together into a single view or layout (I suppose it's helpful that I now know several techniques that don't work). Each time I try, it LOOKS as if all the fields are there, but there is actually no data at all in the layout.

1. Simply not true. You can change a table name and that does NOT disturb any layouts that are based on it. An explanation for what you are claiming might be that you're not talking about tables at all. Maybe you are talking about files. If you change a FILE name then you must use "Manage External Data Sources" to update the file reference.

2. Creating and modifying layouts for your purposes is fundamental to basic Filemaker development and your conclusion is enormously and needlessly self-limiting.

3. It will be a lot easier if you post example files. And at this point no, you do NOT "know" techniques that don't work.

[comment]

Actually, the correct hierarchy is:

A table has table occurrences;

A TO has layouts.

Field names in a script are qualified by their TO name. Changing a layout name does NOT affect the TO, so you won't be noticing this in script steps that reference fields. But if you have a script step that references a layout, e.g. Go to Layout [by name], then renaming that layout will be automatically picked up by the script.

You can create a new layout or edit an existing one, including re-assigning it to a another TO. If you use the wizard to create a layout, the new layout can be styled exactly like a new layout created automatically by Filemaker.

I have absolutely no idea how to bring data from multiple tables together into a single view or layout

It depends on how the tables are related, and what do you actually want to achieve by viewing data from multiple tables together. The most common way, I think, is to place a portal to a child table on a layout of parent.

[Vaughan]

"(3) I have absolutely no idea how to bring data from multiple tables together into a single view or layout (I suppose it's helpful that I now know several techniques that don't work). Each time I try, it LOOKS as if all the fields are there, but there is actually no data at all in the layout."

Portals are used to display records from related tables. A single layout can have as many portals on it as you like (though whether it'll be a useable interface is debatable).

If you haven't already done so, download some of the free open sample files from these and other forums and see how the tables are related together. In general there are only two types of relationships, one-to-many and many-to-many, and learning when to use them and how to implement them is both fundamental and not too hard. :)

[Genx]

... Start with one-to-many.

[aldipalo]

Hi Mark:

As someone who was in your shoes not to long ago the first thing you need to do is some reading. Everyone on this forum is great and will help you every step of the way, but, if you don't have a reasonable idea of how to structure your database things will quickly disintegrate.

Take a look at this post for some suggested reading material:

http://fmforums.com/forum/showtopic.php?tid/199217/

It will be worth the effort.

[tedp58]

Wow, y'all got a bit beyond anything I recognize.

Anyway, what I'm getting from what's been posted about MY question, is that somewhere in the script, I'm supposed to have listed all the fields that should display in the layout?

Not questioning your expertise, but why did it work fine up until March? Could it be a conversion issue? Most recent, regularly used was version 5.5.

[comment]

Anyway, what I'm getting from what's been posted about MY question, is that somewhere in the script, I'm supposed to have listed all the fields that should display in the layout?

No, not at all. All you need to do is change your script as explained in my second post in this thread (and again in the third one).

Edited November 13, 2008 by Guest