Jump to content

Bonnerbl

Members
  • Content Count

    17
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Bonnerbl

  • Rank
    novice
  1. Unfortunately the pdf aproach won't work because of the quality of the output when printed from a pdf rather than directly to the printer.
  2. My report consists of many sliding fields so each record may result in one to many pages of text. I am printing duplex. Each time it starts printing a new record I need to make sure that it is on an odd page. Can someone point me in the right direction?
  3. Can't figure out what is happening. I have a value list with values A, B, and C. The field definition in the table says this field is always validated and the values must come from the value list. The entry field on the screen says it come from a drop down list based on the same value list. When the user clicks in that field, the three choices appear as they should. If the user initially clicks on B, the field is filled in with A. If the user initially clicks on C, the field is filled in with B. In either case if the user returns to the field and again select B the field is correctly filled in with B. The strange behavior is only happening on the initial attempt to fill in the field. Ideas?
  4. They contain text. For example: "Shreve 1920" or "None" or "Pastel". (I had no hand in the database design. Have to work with what I've got :->)
  5. I am importing data from an older version of the database. Unfortunately when the new database was created it used the same field for what were in the old database several fields. For example what was in old data::mark, old date::engraving, or old data::illustrated imports to one new field::model. The difference is if the record is type A then mark imports to model, if the record is type B then engraving imports to model,and if the record is type C then illustrated=model. So I need to do an import and as each record is imported, inspect it for a type, and then do the appropriate import into model. The script "Import Records" doesn't let me make any choices on an input record by record basis. Or does it somehow? Any pointers or advice appreciated.
  6. Interesting. Unfortunately this is PC shop.
  7. Need help figuring out this problem. I have two reports. Report #1 is a simple report layout and the user uses the default Filemaker PREVIEW and then PRINT and/or PRINT SETUP to choose the printer and options. Report #2 on the other hand is printed from a script. The script contains a Print Setup - performed with a dialog and no page setup options chosen. It then later on does a Print[No dialog] without any print options specified. If I print report #1 and click on the PRINT icon in the FM toolbar and send it to printera and then print report #2 but choose printerb in my scripted Print Setup dialog, the report in error goes to printera. It seems that something in the FM system is either overriding my choice in the scripted Print Setup or else my scripted Print command is wrong. Does anyone have some ideas for where I should look. I've spent several days trying to figure this out and am at a loss. Bottom line the printer will always be chosen on an ad hoc basis each time a particular report is run. Thanks for any help, clues, ideas.. p.s. - know that there was an issue with long printer names FM9 and before. I'm using FM10 and 11.
  8. What was missing was a go to field step before going to the portal row. I hadn't mentioned in my post that there was more than one portal on the layout. So #1 added the commit, #2 added the go to field. Works fine now.
  9. Nope. Still not working. The first time I run the script I get portal rows as I expect. The next time I run the script it is not creating a second row. Looks like it is updating the existing row.
  10. The problem isn't that it doesn't find the portal it does. It does add the portal row. The problem is that if you run the script again it doesn't add a second row. It seems to replace the values in the first row.
  11. hmmm. 85 views and no reply. This is what I think will work. 1. create an empty "conversion" database with table identical to the old database. 2. in the new database the script should - ask the user for the name of the database to be converted. - copy that database into the "conversion database" - import from the "conversion" database. My reasoning is that if I have a "conversion" database I can identify it in the script and the import mapping step will display its fields as well as the new database fields. That solves my problem of identifying to the import mapping what the fields are in the old database. Rest of the script is pretty straightforward. So it is a plain ol' vanilla import preceded by a simply copy of old database into the "conversion" database. Does this sound reasonable?
  12. Item table has a historical values table. There can be multiple historical values per item. The relationships is defined that historical values can be deleted/created/etc from the item. I have a script to update the historical values with current info from the item table. What is happening is that it seems to be overlaying the existing portal row rather than creating another one. Freeze window Go to layout [item layout with the history portal in it] show all records go to record/request/page [first] loop go to portal row [last] set field [historical::value; item::value] ..then several more set field lines.. end if go to record/request/page [next;exit after last] end loop go to layout [original layout] When I first run the script it adds the portal row fine. If I change the value in the item record and rerun the script it seems to simply replace the values in the portal row rather than add another row with the new values. What am I doing wrong?
  13. This is similar to 3217167 Importing from old copies of the same database. I have database A developed several years ago. There is now database B with new tables and some similar fields but with different names. I need an automated way to import the old informtion into the new database. I I am now at the point of using the IMPORT command to import. Part of that is the mapping of the old fields to the new fields. But when I go the screen where I indicate the mapping, the source table/fields naturally are not there. 1. How do I specify the mapping if the screen doesn't know what the input database is? 2. Do I copy the old database structure into aa "dummy" database and use it when doing the mapping and somehow overriding it at execution with the actual database name? 3. Or do I have to loop through the old database with script steps setting variables = to the fields and then loop through the new database setting the new fields = the appropriate variables? Really need help conceptualize what I need to do. Thanks! (am sitting in a hotel room with only the internet as my source for how to info. Left the manual at home :-<.)
  14. Iam on F10 and FM11. Have a table of contacts. For various reasons these contacts may be related to one another. I created a relationship table that contains the record id of a contact and the record id of the related contact and the type of relationship. When a user is viewing a contact they have a portal they can use to establish a relationship with another contact. The issue is that users know about the name of a contact but not the record id of a contact. I want the user to be able to go to the portal, scroll through the list of existing contacts, select one, specify the type of relationship, and establish a relationsip with that contact. Really looking for a general approach rather than a detailed solution. Am stuck on figuring out how to do the scroll through existing contacts and the select.
  15. Thank you for the correction to mfero's post. You both told me exactly what I needed. If you read my post again you will see that the reason I needed to create the B records now was that the B table was added to a database that already had records in the A table. Going forward there wouldn't be any problem because B would be created automatically. The essense of my problem was that A records already existed before table B was created.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.