Has anyone been able to sucessfully pass data from Visual Basic back to FileMaker and if so, how was your code written? I am putting together a complex Visual Basic interface for a department (can't be done in FM) and although I can assess and bring info from a FM record up VB, I can't seem to get the right coding to send the data back down to a specific FM record (and update the record).
The best way (or at least the fastest running way) to do this is to have VB communicate with FileMaker via HTTP/XML. VB would send HTTP queries to FileMaker, and FileMaker would respond with XML which your VB could interpret and use. To send HTTP request from VB I think you'd have to use the MSXML2.XMLHTTP object, and then you'd have to load the resulting XML into an MSXML2.DOMDocument which you could then use. (These objects are available through MDAC, microsoft data access components, which is typically installed with a database, ASP, or IIS; but none the less is a free download at Microsoft's web site).
Updating records is a bit more difficult. You'd use a query like: http://my_server.com/FMPro?-db=my_db...2=value2&-edit
The problem here is that you need to know the recid, which is FileMaker's internal record ID (not a serial number that you created). The recid is returned with any FileMaker XML response, so if you've already accessed the record (via a find or other), then you should already have that recid number stored somewhere in your VB app.
If you only know, say, the client company name, and want to update it, you have to first send a find query to identify and return the data for that client record, then send a second query to update the record using the recID returned from the first query.
This method requires you to have setup a computer with FileMaker web companion enabled, and added "web" layouts to your FileMaker solution. The FileMaker license agreement requires you to use FileMaker Unlimited when connecting third party software to the web companion, so you'll need to get that too (further, regular FMP only responds to 10 IP addresses in a rolling 12 hour period). Also, FMP web companion can crash if an HTTP session is disconnected before FMP can respond to the query. To circumvent this, I've set up an ASP page that simply forwards requests to the FileMaker web companion. Then, all software that would send HTTP requests to FileMaker are instead pointed at the ASP page. That way, if a user quits their client application before FileMaker responds (for instance when FMP server is backing up) then while the connection between the client application and the ASP page is terminated, the ASP page maintains the http connection to web companion (for as long as the ASP timeout is set), providing a connection for FileMaker web companion to respond to, and preventing it from crashing. Yes, quite a work around, but it does the job.
BTW, the HTTP/XML method is much, much faster than connecting to FileMaker using ODBC (FMP is an extraordinarily slow ODBC data source). Good luck!
Thanks for your information. But if I'm not mistaken, the web services don't operate in the server (host) enviroment. My system is running 87 files on FM server 5.5 and is accessed by 40+ users. I am trying to pass data from Visual Basic back down to FM records via DAO connections or programmicly. It's the .update record that I'm having difficulty with. I'm thinking that maybe writng in SQL may work. When I do get the data to go back down to FM records the data always ends up in the first FM record rather than that being accessed. Well anyway I'll keep plugging away at it and if I get a solution I'll share it here. (Too bad FileMaker is so limited in its programming capibilities).
Your're right - FMP Server does not have any web capabilities. However, FMP client does (yes, an unusual paradigm). All you have to do is run FMP client on a dedicated machine (that will act as the DB web server) and configure the FMP Web Companion plug-in on that copy of FMP. Since you're running FileMaker companion on a client, the client will only be able to access 50 of the 87 files at once. While this is a problem, you'll encounter the same issue trying to connect using ODBC and the [local|remote] data access companions. By the way, HTTP/XML is entirely programmable and also much faster than ODBC (which I think DAO uses to access the database).
Anyway, best of luck with your project and please do keep us posted. It will be very interesting to hear how the project progresses. (And I'm particularly curious as to whether the users will find the ODBC performance acceptable). Good luck Rick and I look forward to your future posts!