kraftyman

If you are using plain old Server 7 then you're out of luck... ODBC only works with Server Advanced..... and only in Windows so just hand over your wallet...

I don't think you can get away without lots of fields IF you leave it all to filemaker. FMP was never designed to be a statistics tool. The easiest thing is to get the data out to an Excel worksheet and do your analysis there. If you have 22 fields, then presumably you will want a mean score with variance or standard deviation, maybe a count of valid entries as well. This means at least 3-5 summary fields per data field. ( you could have repeating fields for this, but the essential problem of multiple fields is still the same). Excel is MUCH better at this kind of statistics than FMP. The best thing in my opinion is to have the data stored in FMP, then pull it into Excel via an ODBC link. Then you can get pivot charts, the works.... For the man with only a hammer, every job looks like a nail

yes, FMP seems to load the OLE object fully, but it perhapsonly when it is in an editable field. try this: go to field behaviour and uncheck "enable field to be entered" this may speed things up considerably ( it does for images) You may want to have a data input and a separate data browsing layout with scripted buttons

There are no "events" at all. An "on change" event can be simulated by a calculation field and a plugin, see details databasepros.com type "Hidden Plug-ins" to see the page relating to this technique. I'm not sure if I can give you a direct link here Also have a good look at this http://filemaker.advisor.com/doc/14267 which is an excelent article on the subject of migration from Access to FMP7. There are also a few threads on this forum which address your problem directly

Have you considered that maybe the trial version cannot be updated? Similar concept to XP pirate copies being unable to load service packs. Also check your zip file for errors Download accelerators often drop packets and corrupt files The MD5 hash should be dbf27ccc6e257c1065ea7638a6cd74f8 for fmd_70v2_win_updater.zip have a look on http://www.kennethballard.com/ for a decent freeware MD5 checker

The information in the FM help file is actually quite good. I've used ODBC with filemaker since v5.0 and the trick for FM7 is to install the ODBC driver, which is NOT installed by default, for some bizarre reason. ( unlike revious versions) I found myself getting stuck because I was using the old driver... Once the ODBC driver is installed, then follw ithe instructions in the FMP help file, and you should be OK. Send me a message if you get stuck.

Major differences runtime: cannot be networked does not share files (unless data files hosted on FM server, but need full FMP to access them anyway) does not offer full range of import/export file formats cannot modify design of anything no support from FMP - you have to do your own support FileMaker Version: Dev 7 Platform: Windows XP

Something is cooking.... In Australia, FMP is offering 1.$100 cash back for ANY license bought before october 2003, including academic - that is a huge discount 2. Price for FMP Developer 6.5 has dropped from $ 1049 -1079 to $ 799 all of a sudden Why might this be? Methinks the old version is getting the big shove out the door before the new version... Someone must know something guys.

You could also use the error capturing "on" for this script. Try this allow abort off set error capture on go to layout "y" enter preview mode ( pause ) print ( with dialogue) if status (current error) =1 go to layout "x" enter browse mode set error capture off allow abort on exit script end if set error capture off allow abort on Then if the user cancels an action such as printing, error code 1 is created. You could then send the user to the original layout. The only down side is that the user has to press continue, and then cancel the printing to get back to the original layout. You could also have a global field with the number of the last layout entered when that layout is left, and then when the user cancels the script, they caould be redirected to layout number whatever they were in last. You could also design a "pseudo preview" page in browse mode, "preshrunk" to fit a page, with read-only fields and a back button.

You obviously use carriage returns in your felds ( bad move for compatibility) Filemaker translates every return character (ASCI code 13) into ASCI character 11. I don't know why on Earth FMPinc chose to do this, maybe this has something to do with the MAC origins. ASCI 11 does not have a symbol ( at least in windows) . (The FMP help file calls it a vertical tab, whatever that is) When this gets exported to Excel, then all you see is a box. You could emulate this with two cells in Excel. Put 11 in cell A1, then in A2 type =Char(A1) and you'll see a box. In fact the first 32 characters in ASCII do not have a symbol. I'm not sure what you could do apart from creating calculated fields to split the lines in your text fields, before exporting. Hope this helps

Access to other data sources from FMP may be a breeze, but at times a rather smelly one As for your problem, I suspect you may be using the wrong driver. I am not an oracle user, but Oracle may (should) have their own (decent) ODBC driver for this purpose. This is a piece out of the readme for FMP5.5 8.3. The FileMaker Pro 5.5 installer adds an Oracle ODBC driver to the list of available drivers in the ODBC control panel. If you are already using an Oracle ODBC driver, we recommend that you remove the ODBC Oracle driver that is installed with FileMaker Pro 5.5. The FMP ODBC support is not as good as they say it is. Hope this helps

It's included in the standard installation. ( for some reason, custom installations often omit the files)and remember to enable the data access companions. The FMP help files and instructions are reasonably good on this. You may get unstuck with some windows matters, but get beack to the forum to iron these out

No, it simply means what it says. The value should be unique. This might be a numerical, or textual, or even a 128bit binary value ( which is used for replicating databases). If you already have some data, and tell Acess to make one of the fields the primary key, then it will check all the records and make sure the values are unique, and not do what FMP does ( FMP does not check existing records for integrity of uniqueness). IN fact it's a little more complex than that, because there are two "levels" of uniqueness. in one instance, you can simply index the data and set it not to allow duplicate values, in another instance you can also specify the "primary key" setting. The latter is used for very strict relational links that allow cascaded deletes and cascaded updates. Many to Many relationships are handled in the traditional way of having a join table. This is far less flexible than the looser FMP model, but makes it much easier to get MSaccess talking to other databases.

making "relational" tables in access is a snap,you just have to decide which field your primary key is this should be a field with UNIQUE information. Then you Access is VERY strict with this. You may expose the slackness of filemaker in this regard, and have to recreate a unique number. There is a table analyzer and splitter wizard to help you make such decisions. The simplest way to get unique ID's is to add an Autonumber field, and set this as the primary key. This is the default way Access handles ID's. There are problems with it if the data is multiuser/replicated, and other things are usually employed but this is beyond the scope of an FMP forum.... and...... make your tech dude earn his pizza!

Presumably ODBC is not working for you... You could automate the export to the TAB/CSV file, and then set this is up as a data source in Windows, so that Excel could automatically update a worksheet from this data

The short answer is = limitation of MS Access This might seem very weak compared to FMP, but remember that an access file is structured very differently to FMP In FMP the file = data + layouts + scripts + other stuff is all together. There is no practical limit to any of these. However, one FMP file only contains one lot of data. Related information is stored in individual files In Access data is stored as individual tables, and is totally separate from the queries, forms, reports, scripting and other things. You can import /export any item indiviadually. In Access you can have 32768 individual items, you can have multiple tables ( or lots of data) in one file. Each table can have up to 32 indexes. This is not a problem, because there would be few occasions when you might need to index so many fields in one table. It is usually better to split the data into related tables, and thre is no practical limit to the indexes you can have then. When Access talks to FMP, it conects one table to one FMP file. This will work if there are <32 indexes in the FMP file. FMP indexes files to establish relationships, and enable value lists ( ?and other things). It is VERY EASY to exceed 32 indexed fields for this reason. If Access finds >32 indexes, then it cannot split the table, and it just gives up. Lesson 1 = FMP conforms to ODBC but only just. They make it a big sales push, but the reality is not that great. You will have much more success with ODBC when you are pulling data into FMP. Lesson 2 = small FMP files are much easier to manage in this environement than big ones. Lesson 3 = if you know you will be using other software to connect to FMP, be very careful in the original design of your database. Lesson 4 = try if possible to separate data from interface ( very hard to do in FMP) Hope this longer answer is useful

Your problem may be that some text fields imported from MYOB have carriage returns. FMP stores carriage returns in a text field, but when it exports them, it puts stupid ASCI 11 characters (vertical tab) instead. So when your text/csv/mer file is exported, the other software chokes on these silly ASC11 characters. Result = BIG pain in the backside Solution 1 = $$$ If you have a lot of money, you could buy the MYOB ODBC developer kit, which contains ODBC drivers for MYOB and other stuff. Then presumably you could just use Filemaker to read and write to MYOB tables and vice versa. Solution 2 = $ or just time/friends in right places Write a very quick and dirty executable, which will parse and remove the ASC11 landmines. You could do this in VB, VC++, Java as an executable or use VBscript or, Javascript, or use Word/Excel/Access to achieve this purpose. With the latter, it is more messy, but you would just create a macro in an empty file, which could be run with a command line option. Filemaker will be able to launch this for you. Hope this helps

If you only have one file, and less than 33 indexed fields then this is the solution for you. You will be done in < 1 minute 1. Enable sharing of the filemaker database via the local or remote data acces companion. 2.Leave filemaker running 3. go into "administrative tools" in the control panel 4. go into "ODBC data sources" 5. in the next dialogue click "add" 6. select filemaker pro as the odbc driver 7. put the EXACT name of the fmp database including the .fp5 extension 8. click apply 9. open accecc 10. create new database 11. select new table >>import table 12. select ODBC sources from the file type dropdown 13. the ODBC sources window will pop up ( just like the one you had in step5) 14. select the filemaker database you enetered before 15. click ok 16. All done 17. pat youself on the back 18. a raspberry to microsoft !

Quite aside from the ethical/legal implications... This is the blurb from the access help file as background *********************** Securing database objects with user-level security The most flexible and extensive method of securing a database is called user-level security. This form of security is similar to methods used in most network systems. The two main reasons to use user-level security are to: Prevent users from inadvertently breaking an application by changing tables, queries, forms, reports, and macros on which the application depends. Protect sensitive data in the database. Under user-level security, users are required to identify themselves by an id, and then type a password when they start Microsoft Access. Within the workgroup information file, they are identified as members of a group. Microsoft Access provides two default groups: administrators (named the Admins group) and users (named the Users group), but you can define additional groups. Although setting up user-level security on most databases can be a daunting task, the User-Level Security Wizard makes it easy to quickly secure your Access database in a one-step process. Furthermore by implementing common security schemes, the User-Level Security Wizard minimizes and even eliminates the need to use the Security command from the Tools menu. After running the User-Level Security Wizard, you can assign or remove permissions for user and group accounts in your workgroup for a database and its existing tables, queries, forms, reports, and macros. You can also set the default permissions that Microsoft Access assigns for any new tables, queries, forms, reports, and macros that are created in a database. Permissions are granted to groups and users to regulate how they are allowed to work with each table, query, form, report, and macro in a database. For example, members of the Users group might be allowed to view, enter, or modify data in a Customers table but not to change the design of that table. While the Users group might be allowed to only view data in a table containing order data, they might be totally denied any access to a Payroll table. Members of the Admins group have full permissions on all of a database's tables, queries, forms, reports, and macros . You can set up more fine-grained control by creating your own group accounts, assigning appropriate permissions to those groups, and then adding users to those groups. If you only need an administrators group and users group for your security purposes, you don't need to create additional groups; you can use the default Admins and Users groups. In this case, you only need to assign the appropriate permissions to the default Users group, and add any additional administrators to the default Admins group. Any new users you add are automatically added to the Users group. Typical permissions for the Users group might include Read Data and Update Data for tables and queries, and Open/Run for forms and reports. If you need more fine-grained control of different groups of users, you can create your own groups, assign different sets of permissions to those groups, and then add users to the appropriate groups. To simplify the management of permissions, it is recommended that you only assign permissions to groups (not users), and then add users to the appropriate groups. Note For more information on the Microsoft Access security model, see the Microsoft Office 2000/Visual Basic Programmer's Guide. *************** Hopefully this sheds some light. The error message has nothing to do with the operating system. If Win NT/2K/XP doesn't want to let you in, you simply get an "access denied" eror. You are having problems because you do not have the correct information in your workgroup file ( system.mdw) to enable the .mdb to be opened by your MS Access application. There is no simple way to remedy this, because the appropriate user name and password are not stored in the mdb file as such You need to have the original workgroup file, which might be on your friend's computer somewhere ( look for system.mdw or other .mdw files), and then you have some hope. On www.passware.com, you will find a legal product which will decrypt the system.mdw file and allow you to see the necessary passwords. (It is expensive, but having locked myself out of my access aplication permanantly just once, meant that I had no choice but to cough up the money....) If you do not have the workgroup file, then methinks you are quite far up the creek. Then you might have to do some really serious binary stuff...

Simle answer = no Complex answer = no...yes.... well...sort of.......maybe The only way that I can think of is to have a number of different layouts accessible by the user for that purpose. You could create a script giving "small", "medium" and "large" choices for the user, then create a global preference field. Then each time the user navigates to a layout, the script would check the flag, and direct the user to the appropriate layout. This could rapidly turn into a pain in the neck if you want to give the user too many options, and the layouts are complex. I suppose that if you really wanted to give the user this capability, then you might have to relinquish kiosk mode.

Intersting idea, I haven't tried this. I actually do use separte folders for the exported/backed up data anyway. This ensures files do not get overwritten, and the data is always retrievable. The user would launch the new file and import from the old. I must try this from the runtime. There could be a problem since the file names would have to be identical to make sure that all the scripts worked, and the application could get incredibly confused, not to mention the developer... I will let you know how this goes

Re: It's EXTREMELY dangerous to overwrite files -- better to bring in the new version, then import the data, then (and only then) manually delete the old version. I agree but this suggestion would not work with a runtime because the files are bound. Naming files becomes a nightmare. The original file might be called version1.usr and the new one version2.usr. If I get version 3 out, then the version 2 file won't "know" about version3. usr, so the scripts will no longer work, and the user will have to pick the files. There is still the fact that any user interface changes in the new file require the user to delete the old file and use the new. I tried doing this with 3 files with the same name in "current", "old" and "new" folders, but this was already pretty tough. It was difficult to keep up with which script was external, if all files were essentially identical. Now I have and need 16 files. It would be a logistical nightmare to switch between new and old versions like this. Filemaker gives me no control over file names, I would have to use batch file to rename them to stop the user having to do any thinking. Aargh.... No good... Re: Create a "PrepareForUpgrade" script that performs a "ShowAll" in each file so that records are ready to be exported. I have already done this Re:Create an "Import" script that imports records using the "Matching Fields" import order (as opposed to "Last Import" or some other import order) -- you might have to have the user select the file to import from; test it, 'cause I haven't. Oh yeah -- probably a good idea to check the "perform without dialog" box in the import script step. I have already done all of the above too. You will find that if you actually unselect "perfom without dialog" to see what FMP is doing, you will see that something odd happens. The field order is no longer "matching fields", but "previous order". This is my real question. Which previous order? The order entered when "matching fields" was chosen? Or is it the order of the database fields when the script was saved? Or is it the field oder that the database is in since i changed it to "by type" or " by creation order" I don't know. I would really love to be able to disassociate interface from data. Filemaker is limited in the things it can do with related fields, which cause all this trouble in the first place.

I have a runtime solution using 16 related files. When I update some of the data files, I want the user to update the data by themselves after downloading the required files from my site. I'm having some problems getting the scripted update to work properly. Here is the sequence of steps 1. User backs up data to one ( different folder) and exports all useful data fields into another database, into another folder. 2. User downloads a new version of the file, overwriting the old version. 3. User opens the new version of the file, and activates a script which imports all the records from the exported data. The existing records are updated, and new ones imported. ( there is a unique ID a'la CaptKurt's schema but more characters) So far so good. In fact the user activates one scipt from the main file which runs subscripts for both importing and exporting from all the subsidiary files. At one stage I forgot to include the "show all records" script step -doh! What seems to be happening is that filemaker loses the field order during these automated imports, and I get things like dates of birth put into the surname field etc etc. I don't know why this is happening. It seems like all is well when the databases are compiled and sent out, but somehow it falls over later on. I have some theories, and maybe one of the gurus has the answer. Theory 1 Filemaker is stuffed.... Theory 2 Filemaker is OK , the developer is stuffed .... Therory 3 Since I cannot separate interface layers from data layers !@#$%^!, I end up having to work with all the files which get sent out to the users. Since there about 150-180 fields in the main file ( No @#$%^& variables ) I have to sort the fields in the field order quite a few times during the process. Maybe this upsets the applecart somewhere, and Filemaker runs the import/export script steps with the "current" sort, rather than the one I originally intended. NB: I have "restore" checked in the scripts. Theory 4 Maybe Filemaker has some internal preference for field order when running imports export. I noticed that no matter what field order is active at the time, the import and export commands pop up the box with the fields arranged in alphabetical order. (Too bad if you want to rearrange 180 fields differently - have a cup of tea!). This might have undesirable effects. For example, if the file is exported with a field order "by type", this might not be interpreted correctly by an automatic import script, if it wants to be in alphabetical order. Do you know what I mean? In theory, when the import script is created and restore is checked, then, however the field order is defined at this time should be remembered. Currently, I'm going to try to standardise the field order to alphabetical, when I'm packaging the files for the runtime. My bet is that there is a subtle oversight in the design of import/export functions which is the cause of the problem. Any ideas anyone?

You can do it by creating all the required scripts in the "data" file. Then, when you are in the "utility" file, you can run them as external scripts. Make sure that you choose all records, or just the subset you want updated/exported/imported because when the script runs it will affect whatever the "found set" is at the time.

The answer in a single word is no. FMP does not respond to events as such. I don't know about the MAC version, but this is certainly the case in windows. However, not all is lost. You can get a schedular plug-in which will trap for the tab key press to change fields, or arbitrarily run every x microseconds, and thus activate a script. Alternatively, you can create ascript which will re-lookup the data. This might be a subscript in any other script which allows the user to navigate away from the current layout. In effect, you are using the human as an event trap. I noted your use of lookups, would a related field not be better for this setting? at least this would update automatically based on some criteria. hope this helps