FileMaker data types are not comparable to Access/SQL ones, and you will need to take this into account.Ī) There is no integer, long int, float, double, etc. Experienced FM developers generally avoid this, but it's perfectly legal to have a FileMaker field called "This is my field name/isn't it great & wonderful?"Ģ.
FileMaker allows field and table names that are illegal in ODBC and Access. You will need a separate DSN for each FileMaker file.ġ. You'll need to turn on ODBC sharing for the FileMaker database, which is off by default, and you'll need to install the ODBC/JDBC drivers on the client machine, which are a separate install on the FileMaker installation CD. >If i indeed use FMP as the backend, will Access see it (tables) in realtime like it does with SQL Server? Is this true? or can remote tables be treated as through they're local like MS Access? the logical nature of displaying remote tables as though they are local is just not there. I've done some investigations, and it seems that Filemaker, through ODBC, requires scripts to perform SQL statements (to be defined by the developer) on tables at the remote end - i.e. use FileMaker Pro as the client end, and SQL Server as the back, I was wondering whether there is this facility to 'link' a remote table and have it display as a local table, like MS Access. This was achieved by 'linking' the SQL Server tables via ODBC (system / user DNS) - this integration ability is seamless and logical, especially for scalable deployment.Īs I'm hoping to duplicate this deployment model for FileMaker Pro - i.e. With MS Access, I've been using Access as the front end client (with all the business logic), and MS SQL Server Database as the back end database / data repository. I've been developing on MS Access for quite some time now, and recently I have been asked to do a few things with FileMaker Pro.
0 kommentar(er)
