Howard LeCanard

Thank you.

I know that peer to peer sharing has been deprecated. I also know that it still works on my network between two computers. My client has a two-person shop and has been doing peer to peer for years. He wants to upgrade from an old version of FileMaker to 19 because he is getting new computers. He has been hit hard by events this year so he wants to spend the minimum amount. My versions of 19 are part of a volume license, so I don't know if p2p sharing is only working because of that. Would it work with two or three individual licenses of 19?

I just read on one of the email lists that others were having this problem. They fixed it by not including a name in the SMTP settings. That fixed it up for me too.

I've tried ports 587, 465, 25, 110, and checked and rechecked that I brought all my settings over faithfully from Mail. I still get error 1506. I can't find any security settings that try to dictate what apps can send mail. Could there be some other thing happening in the OS? Is there a log somewhere that will help me get a better idea of what the error is?

My ISP makes me use port 587, which is wide open, thanks.

Oops! I haven't even looked at those prefs in ages (obviously). Yep, I'm using FMPA10 on OS 10.4.11. I filled that in when I was entering my topic, but I guess it didn't show anywhere.

I have faithfully copied my smtp settings over from Mail, but despite an hour or so of tweaking, can't seem to get an email to go out. I keep getting error #1506. Is there a trick to this? I mean, those exact settings are working fine in Mail.

Jeff, As Vaughan said, word of mouth is important. I started out doing filemaker development for my employer. My first client was a company that hired an ex-coworker. She said that in order to do her job properly, she needed a database, and she knew just the guy to do it. My second client was my sister's employer. After that, I joined the local user group, and met up with some guys who were too busy to handle their own workload. Now I mostly do subcontract work, which pays much less per hour than my own clients do, but there is much less effort involved as well.

Okay. Just one more thing. You should read this article from Joel on Software. In taking the whole idea of database schema design to this very high, generalized degree, you are what he refers to as an Architecture Astronaut. You're proposing to not see the trees for the forest. However, I mean that in the nicest way possible. I don't mean to start name-calling.

OK. I can't keep quiet on this. I'm all for reusability, and I can appreciate that there may be some layout reusability available with this model. But won't you lose some of the elegance of the layouts? Until we can create truly dynamic layouts in filemaker, you are stuck with having a static position for all fields and labels on the layout. You'll end up with data that should be shown in a certain order on the layout, being shown in a predetermined order by what reusable fields you are using. You'll probably say that you have to plan this kind of thing very carefully before creating the database, and you're right, since filemaker 7 came out, we've all found efficiencies by doing more planning for our files. But with the continual spectre of scope-creep and new features and modules, there is just no way you can plan for every eventuality. Once again, I'm sticking with my original view that the headache in creating a model like this for a complex database will override any benefits by a long shot. The main benefit you've shown is ease of reporting. I'm not convinced that's even a benefit. If everything is tucked away in its own little table, it is very easy to find the data for a report. On the few occasions where I have ever needed to have a line item report that pulls data from disparate sources, I've always been able to either find the best compromise to get the user the data they need, or I've created a utility table for that report. The utility table method can be a bit cumbersome, but it is usually the exception. Most of these situations can be avoided by doing a thorough analysis ahead of time, and finding out what the client really wants the data for before you create the tables.

I don't think I'll be able to change your mind, Raz. You definitely haven't changed mine. And now, I am bowing out.

Raz, I think you are really over-estimating the time and effort involved in making schema changes. Adding a table and relating it to your current structure, or changing a table's place in the relational structure can be done quite quickly, even in the most complex of databases. As a meta-consultant, I would recommend that the client build a good template file, that has a reliable contact module in it. After that, I would tell him to make sure that he has a firm understanding of data theory, so that it is not difficult for him to create new tables, TOs and relationships on the fly. After all, I've seen a lot of extensive template files that really restrict the developer (okay, ME) by having too much created ahead of time. Since all our clients have different businesses, expectations, and desires, there is no way to streamline our processes too much. A lot of it is a creative process, just like for a Web developer. The Web developer may have a few template CSS pages that he starts with, but there are too many variables in each project for him to go beyond that.

Raz, This whole exercise seems to be a lot of work to go through to make sure that you do things differently. I can understand that imports, and data transfers may seem easier if you're new to FM7/8, but once you get used to doing things the new way, I think you'll find things aren't as tough as they were. In FM6, if you wanted to script an import of a bunch of data, you had to go into each affected table, and create scripts to prepare the table, perform the import, then do any further processing. Then you had to create one script that managed all these import scripts. In FM7, you can do it all in one script. Just change layouts to work on a different table. You can develop a solution your suggested way, and have to document what each field is based on what type of record you are storing ... OR ... you can develop using the tools FMI provided, the way they intended, and not have to look at your documentation to discover the use of every field. I prefer to look at a field name and know what it is. For example, a field called NameFirst, in the Contact table is the first name of a contact. What is field Text1 when the record is a contact record? Better look at the book that you wrote to document the solution! All that being said, it would probably be a fun exercise to create a solution the way you suggest. I just wouldn't want to have to maintain it!

I have done both. Like Ender said, the solution that I kept locked was a solution that I planned on reselling. My original quote included an additional fee if they wanted to buy the master password from me. With all the customizing they've had me do, that fee is actually very low, but they're happy with my work and are uninterested in hooking up with a new developer. The open solutions that I've done have been pretty much the same result. I include a line in all my quotes now that says I will supply them with the master password, but encourage them not to use it, to make it easier for me to know what state a database has been left in. So far, they keep calling me for modifications.

I have no computer training. My degree is just a general business admin. I started playing with FileMaker, then read every book and forum I could find. I've recently become self-employed as a FileMaker developer. There are a lot of good companies out there offering great FileMaker training, but I haven't seen much that tells you how to create good interfaces, or design good commercial solutions.

That's a great way of handling it! I'm wishing I had walked away from this particular set of files.

Don't walk. Run away from EasyAccounting! It is poorly put together by someone who obviously knows nothing about accounting. They say that it is easily customized, but that's a crock. The programming is so convoluted that the best of programmers can expect to make no sense of something as simple as the calculations for multi-state buttons. The database seems to be doing OK when you first start out. But after a few years of transactions have been posted, the flaws become evident.

Ian, I've attached a zip file showing how I'd do it. I hope this helps. fifteen.zip

Okay then. Maybe I should say that script debugger is the only thing I found earth-shattering. I've bound a few runtimes just to try it out, but haven't found much practical use for them, the same with kiosk. I'm afraid of permanent removal of admin access, and I develop everything in one file, so file renaming is no big deal (it was a huge deal pre-7!). Menu renaming only applied to the Scripts menu; since I had told all my clients to stay away from the Menus and only use the buttons I provided, it didn't seem consistent to use that. DDR is kind of nice for searching for specific elements of a solution, but I've found that printing to a pdf provides an interface I prefer. Custom functions are cool, but easy enough to live without if you're not into the whole recursive thing. I'm probably just too ignorant to have found the untapped potential there. But FileMaker Advanced 8 kicks ass! It does everything!

Yeah. This time around they're really giving us a reason to buy the developer version. In 7 it was only helpful if you are into using the script debugger.

Pretty smart.

All right! I can't figure it out. How did you do it?

Despite the cheesy title, here's a good book: GUI Bloopers

I've also heard it's a Windows problem, but if that's the case, then why can all Web browsers do it? Especially now that we have menu control, we could provide a pretty slick interface if we could just make filemaker behave like the browsers do.

It's a simple update. You don't need to make any changes to your 7 files for them to work with 8, but once you see all the cool stuff that 8 can do, you'll want to start incorporating that into your solution.