Wim Decorte

Moderators
  • Content count

    5,167
  • Joined

  • Last visited

  • Days Won

    132

Wim Decorte last won the day on April 21

Wim Decorte had the most liked content!

Community Reputation

418 Excellent

4 Followers

About Wim Decorte

  • Rank
    member
  • Birthday 12/17/1968

Profile Information

  • Gender
    Male
  • Location
    Toronto

Contact Methods

  • Website URL
    www.soliantconsulting.com

FIleMaker Profile

  • FM Application
    15 Advanced
  • Platform
    Cross Platform
  • Skill Level
    Expert
  • Certification
    7
    8
    9
    10
    11
    12
    13
    14
    15
  • Membership
    TechNet
    FileMaker Business Alliance
    FIleMaker Platinum Member
  • Title
    Sr. Technical Architect
  1. No to what? I know some of the folks that responded here personally and we all make a full-time living of working with the FM platform. At the company I work for I lead a 25+ team of full-time FM developers. So the question of "Is anyone making a living off FM?", the answer is a resounding: "yes!" So I'm guessing you're answer is more in the realm that you don't believe in FM's future? Care to elaborate?
  2. Pick your preferred credit card processing gateway (based on overall terms they offer, what cards they cover,...) then look at what integration APIs they offer and then see how you can use those APIs. There are some products out there that already do this, google on 'filemaker plastic' for instance... But if you are really on FM 11 still then you will have a hard time with this, that's very old.
  3. If this description is what you mean by 'open', then: no. FM's scripting is proprietary. It does allow for running external things through plugins etc but you'd have to find one that you like to do this. I think they exist for python but not for swift. The size of it (20GB) is sorta meaningless, a better measure would the the # of records and the # of fields per table and a better understanding for us on the nature of the manipulations you'd expect to do on those records. If you have 20 million records for instance and expect sub-second summary calcs on those then FM is not the tool for you. FM does have a pretty good ODBC/JDBC and XML API. The python API you have found is a wrapper around that XML API, that one only works through FMS. xDBC works locally on a copy of FMP but the calls to it also have originate from that same machine. There is a hybrid solution for you: FM does have native support for MySQL databases. So you could keep your heavy-duty record manipulation outside of FM but still use FM as a GUI to your records. Check out the ESS feature as it is called (External SQL Sources).
  4. http://help.filemaker.com/app/answers/detail/a_id/6420/~/which-odbc-data-sources%2Fdrivers-are-supported-with-external-sql-data-sources%3F It means you can not rely on FileMaker Inc for any support. You couldn't call on support for FM11 anyway at this point in time but forcing a feature outside of support parameters shows a willingness to forgo support. Most companies I work with would not be comfortable with that and it would disqualify any work that I do to make it so.
  5. The question then is: do you really need to work with found sets of a few hundred? Probably not if you analyze it. Nobody can keep a mental overview of a few hundred records. It's easy for us because we can let up to the user to sort and get to the data they need. But the fact that need to sort a few hundred records probably indicates that only need to see the 10 or so records as per the sorted. So perhaps you can give them just that directly. The same applies for WebDirect; designing for this kind of WAN performance is all about performance and user experience (no delays). So think thrice about all the data you make transfer between the server and the client...
  6. Not sure what more to say; the screenshot doesn't lie. If it used to work before then do as it was before; clearly something was changed in the user's Citrix session because that Outlook profile error is not a FM dialog, it's a Windows one.
  7. The 'no longer responding' error: FileMaker Server and FileMaker client are in constant communication. This error happens when that communication can't happen, usually because of bad network connectivity so your troubleshooting efforts are not in FM but on the network side of things. The obvious: make sure the FM Server is on a static IP, not DHCP. That error however is not related to the screenshots. The screenshot error is exactly what it says: the user does not have an outlook profile and you are probably using the "Send Mail - through client" script step. Two ways around that: work with your Citrix guys so that each citrix session does have an outlook profile and can launch Outlook. Or, use "Send Mail" with the SMTP option instead option.
  8. Not in a secure way because it means hard-coding the credentials somewhere. The whole idea is that if a user needs access to a file, he needs credentials in it. If you don't care about security that much you can use the APIs to open a file (fmp url, ActiveX, AppleEvents) and hard-code the password. If you don't want to maintain individual accounts in a file, look at using External Authentication to use groups, which is infinitely more secure.
  9. It is possible but as was mentioned before; it is not a good idea to use the host machine for anything else. Using FM Pro as the host is not as robust as FMS and making that whole deployment even more fragile by using the machine as a workstation is just asking for trouble.
  10. Clearly the file was damaged and in order to make it open FM had to delete large chunks of the corrupted file. In this case that were data blocks. Nothing much that can be done with it. You can try to recover with different versions of FM. You can try to recover on Mac and on Windows. Those are all long shots but you never know. What it really points to is that the file was used in a manner that led to this corruption. Very often that is because of OS-level file sharing, AV scanning,... If you have other FM files in use, carefully scrutenize your deployment to make sure you minimize the risk that other files will get damaged.
  11. We would need to see your script to be more helpful but try the error capture immediately after the first Set Field. Or perhaps even do an "open record" before attempting to write to it.
  12. Good for you. For production I would not recommend it since it is not supported.
  13. We would need to know a lot more detail about the process / workflow that you have going...
  14. Remove the web viewer from the layout and see if it still crashes.
  15. Do you have any onTimers on the any open windows? Is there a web viewer on any of the layouts involved?