I'd say eliminate the versions entirely. I don't see much utility between posting in FM 14 vs FM 13. If that's too drastic a change, what about reducing it to just file formats. FM 12+, 7-11, 3-6, pre-3?
Sounds like there are two issues...Allowing users to enter old contract IDs and not having gaps. You can solve the first by having three fields total. Auto-enter serial, OldID, and a calculation that displays the Old if present otherwise shows the Auto-enter. How do not have gaps is another issue completely. One possibility would be to create a few hundred records that represent the old contract with a blank serial ID, and then start the serial ID at the highest old contract number.
Why do this? There are two elements to what you're asking. One is storing different elements of a name. In general, I don't store middle names in a field in a table without a good reason. I sometimes don't even have a separate first and last name (rather than a single name field). Why nickname and alternate? Why all these different attributes? How will this help your users? The second issue is that you're also saying you want to store each name element in a separate record. Why would you do that??
I see what you mean, you don't have control over the new table structure. Some systems will do the migration for you. "If a 3-employee mom-and-pop store wants an inventory system, it takes just as much code as it does for a 5,000-employee manufacturer. " I'm going to have to disagree here.
Paying someone to review the work is probably worthwhile. I've done that for clients before. Both times my recommendation was to start over. With respect to migration...If the data is properly normalized then it should be no problem moving it into another system, no? And if it's not, you've got to migrate again anyway. I've done dozens of migrations, from Excel, from Access, from Lotus, and they're usually equal 50%-100% of the actual base development time of the alpha version. Even Joel has a caveat in his article about not starting over: "...when applied to large scale commercial applications."
Thank you. You can test to see if adding a pause between each send helps. I like to use a random pause, between .1 and 1 second long because I use Gmail and those guys are smart. They might catch on if I was using the same length pause each time.
If you'd like to pay back, this is the link to donate to this site:
The Modular FileMaker file you're referring to is script-based account management. It's not "layout-based". If you have a limited number of combinations of layouts/layout objects you want to hide, say a dozen, go ahead and create separate privilege sets for those, limiting layout access. Then for the objects, you can put a simple get ( AccountPrivilegeSetName) for the Hide calculation. Also, take a look at Extended Privileges. That may be a better way to conditionally hide objects than the Privilege Set Name. If you got hundreds of possible combinations (new user, PM abuser, accountant, etc etc etc etc) that would required hundreds of privilege sets...then you may want to look at another solution.
Why are you sending the e-mail twice? And is the attachment working correctly? If you want error capture, then after the Send Mail, use Get ( LastError ). If that returns true, collect the e-mail address and error. If it actually works sometimes, your mail server settings are probably correct (otherwise you could never send). It could be a malformed e-mail address. It could be your outbound mail server false reporting an error. It could be your outbound mail server thinking you're sending spam. It could be your outbound mail server thinking you're sending too large an attachment. Collect the actual error, that may provide more information.
"If I jump ship now all this will be lost." The old "sunk cost" fallacy. It buries a lot of businesses. Don't fall for it. Forget what you've already spent, both in sweat and dollars. It's hard to accept, but it's irrelevant to what you should do next. What you have isn't irrelevant. It's a buggy database with your data in it. That's worth something. Not $15K, but something. It sounds like you think your choices are: 1) Continue with the current developer 2) Continue with the current system but a new developer 3) Find a new system. What's the likelihood of #1 being successful? (Pretty slim based on your description). #2? As a developer, based on your post, I would scrap everything you've got and start over from scratch. It'd take me more time to get up to speed on another (or two), substandard, developer's system than it would be to start from scratch. Quit now. Go with #3. Whether that's Spire or another Filemaker developer or some other system depends on your needs. Which is a big conversation. Please keep in mind, you had a developer who wasn't professional and another who couldn't finish the job. But you tolerated these relationships for two years! You need to look at your management style, at your business, and see what went wrong here or you'll just repeat it. It sounds like leading by abdication and not delegation but it could be something else.
Zero and "blank" are different things. The field formatting checkbox displays the number even if it's zero. That's different than "displaying zero if the value is blank". Your fields need to contain the number zero if you want zero to be displayed. Change your calculations so they return zero. Give your number fields a default value of zero.
When doing imports, I usually use several tables. At least one for grabbing the data, and another for the final product. You do your "data transforms" in a later table. It's hard without seeing the data, but I'd say you want the table you have now ("raw data"), a "mapping" table, and the "final data" table you do the actual import into your live data file. You import the data into the "raw data" table. Run a script that fills out the "mapping" table. That will be table with all the field names in your "raw data" table. Each record will be a field name in the "raw data" table that is set by script (that loops through the first record and reports back the field names based on the headers). The "final data" table will be calcs that look to the mapping table to pull the correct fields from the raw data table. Sorry if this is a little abstract. One benefit of having several tables means you don't overwrite important data.
Set Next Step is used when debugging scripts. Say you have a loop that goes through a 1,000 records then does something else. You know the loop works, and want to just test the "something else" (which doesn't require the loop). Set Next Step allow you, as a developer, skip the loop. Users, (who don't have access to the script debugger and privileges to edit the script) won't be affected. And it only works on the script that's currently running in the debugger. It doesn't toggle. If you don't want it to skip and clicked on it, you simply set the next step you want to run, which is the current step!