Scodigo, Inc.

Hi Scodigo!

I think this feature request will not only make me, one user of your product, very happy; I dare say that it may become a 'target feature' for potential customers, and could indeed be one of those where all the rest that SmartPill does is moot and the decision will be for this feature.

Okay, now that I have over-hyped myself, what the hell is it?:

You have this amazing way of Querying FileMaker tables with SQL code. Very cool.

One of the first things you learn in the traditional PHP Learning Curve is of course a direct Query of MySQL (or other). And there the first thing you have to be attentive to is Username and Password -- it is supplied by the calling php code to establish a connection. ("$m = mysql_connect('sandbox.scodigo.com', 'sandbox_sp', 'test');" from your own example)

Okay, so now I am poking around in your examples for fm_sql_select(). I notice something... No Connection is established!

If you added:

fm_sql_connect()

as a new function think of what that opens up!

I have complained on various lists that when one connects to an external datasource other than FileMaker one has a benefit that FileMaker doesn't even offer to itself -- the ability to pass authentication parameters dynamically in the logic! Instead if you are using a FileMaker datasource you must juggle the permissions gingerly so that you remain secure but allow unfettered access to other FileMaker datasources so as not to have to redundantly build every object for every application. This can rise to the level of agony when an organization commits strongly to FileMaker -- indeed, I have written my own Username-Password gizmo that validates the individual and then invisibly logs onto the FileMaker permission set via a discreet set of group accounts. But I hate to do that because I throw away lots that FileMaker offer [Get ( AccountPrivilegeSetName )] and so on.

If I write a script that calls another FileMaker file, that call should be able to programatically pass in the authentication parameters, and those parameters should be able to be totally independent from whatever authentication parameters are current in the calling script.

So...

Until FileMaker gets its act together, SmartPill can be the answer with fm_sql_connect()

I fully admit, and it may be obvious to you all by the content, that I don't know the feasibility of such a command -- but based on the rest of the wizardry you have been able to effect in SmartPill I am guessing you could.

Indeed, the obvious use of fm_sql_connect() would be the same as the rest of them in PHP, offer the resourse for the subsequent fm_sql_select() call and know that it won't be blocked due to permissions.

Moreover, if at all possible fm_sql_connect() could be something the exposes the target FileMaker file fully authenticated as a FileMaker datasource and its sole use (by some users) would be to circumvent the inability of FileMaker to programatically authenticate. So I could imagine that a developer might write this code:

PHP_Execute("fm_sql_connect(fmserver.myhost.com, HRdata.fp7, programatic_access, pr0gr@m@t1c_@cc3ss)");
PeformScript("HRdata.fp7::PrintReportOfAllEmployeesWhoAreUnder21");

to allow the employee picnic planner to get only the pertinent data for the party from the otherwise extremely locked down HR.fp7 system (pseudo code of course)

How amazing would that be?! Indeed, I could imagine writing an Access to External FileMaker datasources 'abstraction layer' to my FM Applications using at its core the Factory Pattern and fm_sql_connect().

It is essentially the "Run script with full access privileges" checkbox for inclusion of external FileMaker data sources -- that is, FileMaker has great access privileges system, but allow a developer to authenticate access to any data programatically!

Again, instead of waiting for FMI to get around to this (which they may at anytime), why not, in the meantime anyway, make it a reason for purchasing SmartPill!

Thanks,
Brad