hayesk

I have searched for this to no avail. Does anyone know of a way to import qfx files from online banking sites into FileMaker? The data type is OFXSGML Unfortunately, I have a long history of qfx files and can't go back and re-export them as csv. They also have transactions from more than one account in each file that other online banking apps don't seem to support. Thanks.

One thing I have noticed is that most people who want a new feature believes their feature must be the most important or popular, and anything else means the company doesn't care about their customers. This is simply not true. FM9 doesn't have what I want it to either, but I don't believe for a second that FMI is only adding the features they want to without regard to developers. Like it or not, some features just happen to be a higher priority than others.

And they stopped doing it for a reason. In effect that is saying more of what your clients pay should go to your pocket instead of FileMaker's? FMI developed the networking code, shouldn't they get paid too? Now obviously I don't know your cost structure for your business, but the fact remains is that it costs you to develop solutions and it costs FMI to develop the tools that allow you to develop solutions. If your clients can't afford it, they can't afford it. Peronally, I think FileMaker looked at the costs to offer network clients, and it was probably so small a difference than being able to offer volume licensing for FMPro that it didn't matter. If FM offered a network thin client at $150 per seat, and FMPro at $160 per seat, people would complain that the network client wasn't cheap enough given that FMPro contained so much more. Yet the cost to FMI was probably fair.

Regarding corporations needing networked runtime because of the cost of full versions. No they don't - they buy huge licenses and discounts are built in - it's not like they are paying $300 per seat. The fact that each network seat gets a full copy is probably a bonus to them. FM has to stay in business and pay their developers - cheap network runtimes aren't going to happen. This should have been obvious years ago.

Regarding keyboard shortcut to Custom Functions FYI, I don't know about Windows, but on a Mac you can assign a keyboard shortcut to any menu item. Go to the System Prefs and click on Keyboard. There is a section for assigning shortcuts to menus.

The reason I've done it in AppleScript is that the data comes from another application. I've managed to work around it by setting a global search field and then calling on FM to run a script to do the search. But this used to work. Yes, the workaround works, but why should I have to use it? Searching in a calc field through AppleScript should be a perfectly reasonable thing to do. Ah well. Thanks for the replies.

Here is what I have done: On a layout I inserted a movie (audio-only) that plays back perfectly. When I switch to another layout that contains the same record, but in a portal, when I try to click in the container within the portal, it asks me to record a new sound rather than playback the movie. If I then re-import the file in the portal, then it plays back. Question: why won't it play back in the first place? Why do I have to re-import it from within the portal before it realizes there is data there? It's as if the portal isn't getting the data the first time. Thanks.

I have the following script: tell application "FileMaker Pro" go to layout layoutName of database databaseName show every record of database databaseName -- this should do the find, but for some reason, I cannot enter data into a calc field - even in a find request delete every request set myRequest to create request of layout layoutName set cell mySearchField of myRequest to mySearchText find end tell For some reason, when mySearchField is a calculation field, I get a "Write permission denied" error in AppleScript. Even those if I get permission on the field it shows I have write permission. I can also manually search in this field on the layout that works. If I change it to a regular text field, it works fine. I'm sure this worked in previous versions. Is there a reason why I cannot seem to search in a calc field using AppleScript? Thanks.

Here's what I would do: My data entry layout is based on task table. I have a global field (temp_projectName) and a value list that is all of the project names in the project table. I also setup a relation from temp_projectName to another occurance of the project table. The data entry layout contains - project id (for when the user knows it), - global temp_projectName field, formatted as popup list set to the project name value list - other task fields When the user clicks "ok", a script looks up the related project id using the new relation (from the temp_projectName field), and fills it in if the field is blank. If it is not blank, the field would have to validate itself based on the regular related project table.

I would make a generic reporting table with generic fields - import from the others into that and generate the report from that table.

I think you could do: - SetField(currentportalrowGlobal, Get(PortalRow)) - Commit record - Go To Field(Field in portal) - Go to Portal Row(currentPortalRow)

I've done it many times. It works just fine.

Hmm... try resizing the portal, give it a scroll, and then resize it back.

Thanks, that's not a bad idea. I'll try that. But I still wonder why the database works correctly locally, but not on the server.

Using MacOS X, FMServer Adv 7.0v2, connecting with FMDev 7.0v3 on MacOS X(different machine). I have a Name table and a Gift table. On my Name table's main layout I have a portal to Gifts. I want it so that the user does not see their own gifts. So I have the View privileges set to GetAccount(Name) != Name in the Name table (with the proper "doesn't equal" symbol) and I have GetAccount(Name) != NameTable::Name and IsValid(NameTable::Name) in the Gift table. If I view a layout from the Gift table, it works fine. The user sees all of the records except his own. But if I look at the Name table's layout, the portals are blank for every record. Here's the weird part: If I take the file off the server and open it locally, the portals display the data where they should. Also, if I remove the restrictions from the Gift table (i.e. set them to all viewable), the portals work, but of course, the user can see his own gifts too. So, why would this work locally, but not on the server? Thanks.

Just use the regular MacOS X. The Server version doesn't give you any additional functionality for serving FileMaker databases, unless you plan on using a RAID disk array - I believe Server comes with management tools for that. Also the 10-client limit is for file sharing - nothing to do with FileMaker - but a moot point since the regular MacOS X will probably be fine.

Well, it's cheaper than FM's competitors. And the open source databases will cost much more in development time. Really, FM is a bargain compared to the competition.

Have you upgraded FMServer before installing FMS Advanced? I believe FMS Adv. came with an updater you need to run first.

Yes, but the question still applies, just a misnaming of the external authentication technology. How does FMS handle privileges when the user logs in through Active or Open Directory?

Thanks, Vaughan. I'm going to use a combination of calc fields and layout access. I am worried a bit about exporting records though. I want the user to be able to export their own records, but not the records of others - this could be tough.

For iCal, there are two ways: 1. iCal uses the standard vCal format. The best way is to create a calc field that takes all the other relevant fields and makes a vCal entry. Then export only that vCal field for all records. You'll have to look up the vCal format to do this - or just look at iCal's data file (I think it's in your Home folder/Library folder somewhere. 2. Make a script and loop through all the records, and use an AppleScript for each record to make a new entry in iCal.

Put a field validation on the field that indicates it must be already in the value list.

Well, 4 isn't several - it just means running the script 4 times. As for LDAP - I'm not sure as I haven't used LDAP yet. I believe you still create the usernames, but the password authentication is controlled through LDAP. I don't believe you enter the name of the privilege set on the LDAP server, but I could be wrong. Look on FM's web site in the Tech Briefs section. There are two articles on security and I believe they address the issue of privilege sets for LDAP authenticated users.

What kind of audit requires sequential numbers on invoices? When you use paper invoices and you throw one away, there's no problem. It should be the same for electronic. Anyway, that's not for me to decide. If it is for audit purposes then I wouldn't allow deletion of invoices at all. Just mark them void. When searching, script the inclusion to omit all voided invoices.

If you turn on "Show compatible script steps" in the ScriptMaker, it will show you (by greying) the steps that are not compatible. It's just a matter of going through script by script.