jware Posted May 26, 2009 Posted May 26, 2009 I would like to create new fields using information entered via an entry screen. For instance, if "Bank of America Visa" is entered the script will create a field with the name "Bank of America Visa Amt" and a field with the name "Bank of America Visa Amt Sum" which is a summary field. I have not been able to find any information on this question so it must be too simple or is not needed by anyone else. I am using FMP Pro 9 Advanced on an XP machine. Thanks for any info. Jware1939
Lee Smith Posted May 26, 2009 Posted May 26, 2009 Why a Script, It sounds more like you need a Related Table. Lee
David Jondreau Posted May 26, 2009 Posted May 26, 2009 You can't script the creation of fields. And you shouldn't be creating new fields in the situation you describe. There are other, more appropriate, ways to accomplish what you're trying to do. But you'll have to tell us you goals, before we can help.
jware Posted May 26, 2009 Author Posted May 26, 2009 I created a database using FMP7 that track my home finance: budget, income, spending, etc. The program has several tables. However, whenever I need to add a new expense item name, or new income item name, for tracking purposes, I had to go into the code and create new table fields so the items could be tracked, summurazied, and included in reports. I want to rewrite the program using FMP Pro 9 and take away the need to go into the code if I get a new credit card or a new income source. Now I know that I have to find another way to accomplish this task. Thanks for the responses. Jware1939
Fenton Posted May 26, 2009 Posted May 26, 2009 When you create and name fields for specific items, it may seem simpler, more like the spreadsheets you may be used to. But eventually it gets to the point where you have too many, and maintenance becomes a burden, as you've noticed. The answer is to use a more "abstract" structure. You will see this method in almost all modern programing. Rather than creating a specifically named field for a different "credit card," or whatever, you use more generic fields, then use one of the fields to label what the value is. I'm not explaining this very well, so I'll use examples. Record 1: Field name: AccountType, Value: "Credit Card" Field name: Amount, Value: 200.10 Record2: Field name: AccountType, Value: "Checking" Field name: Amount, Value: 122.33 So now you've handled 2 different Account Types and their entries with only 2 fields. You could add more fields to say more about each transaction record (Date, memo, etc.). Yes, not very spectacular, but it cuts down on the number of fields. More importantly, it lets you add up the Amount field as one field, for both account types, either as a Summary field, or using an aggregate function via a relationship, from a parent table. There is often a practical limit of how far it is useful to go with any given set of data. But if you have no abstraction of data your functionality and flexibility will be limited, though your development time is increased. FileMaker is a database not a spreadsheet, and you can get more out of it if you can abstract your data to reasonable limits.
jware Posted May 26, 2009 Author Posted May 26, 2009 Thanks for your response, Fenton. I agree with what you are saying about it get difficult when a lot of fields are involved. However, at this point writing database programs using Filemaker is a hobby for me, since I am retired. I was a mainframe programmer using COBOL long before the PC came along. During the last 10 years of my career I did write DB programs using Filemaker Pro verions 3 thru 5.5. Of course Filemaker changed the way they do business starting with version 7, which I bought and wrote a few personal DB programs. The program I am working on now using version 9 I wrote earlier using version 7. It work great in v7 with almost unlimited reporting. Of course I have fields that you mentioned in your reply. I can see a report that show me CREDIT CARDS, and a total; MEDICAL and a total, etc. However, I can also see a report that show VISA1 and the amount; VISA2 and the amount, Bank of America Visa and the amount, etc. This information can be seen for this month, or any other past month since this item has been in the database. Of course I hard coded all the field names, including summuary names while writing the program using v7. Now I want to totally rewrite the program and get around the need to go into the code when adding an item to the database. Hope this explain what I am up to. I will get it done. jware1939
Recommended Posts
This topic is 5661 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now