Ted,
No problem here.
I realize that there's ALWAYS more to the story than what you first
encounter, and there are always reasons to do and not do anything you do
do...but after doing this for nearly 30 years, I find myself looking for
"nifty" little activities like this that make life interesting. It also
seems like a really common 'need,' even though I can't recall ever
thinking it would be a good thing to do before...
Anyway, as someone else said, let the server be the server and serve. If
you have a question, ask (query.)
Thanks for everyone's input!
Mike
Ted Roche wrote:
On Tue, Jun 24, 2014 at 6:11 PM, Mike Copeland <[email protected]> wrote:
I was simply 'wondering out loud' if such a process was possible
(communicating upstream from server) between MariaDB and VFP. I can see a
lot of places it would be useful, but what triggered the question is a
simple scenario where a manager would be monitoring as minions process
inventory returns...looking for anomalies and incomplete data. The returns
are on-going all day long and can sometimes not 'happen' for several hours,
or there can be two dozen in 10 minutes. It is really nothing more than a
simple monitoring process.
OK, sorry if shot you down on purely pragmatic reasons. It's a more complex
solution, possibly more fragile, and would require a lot of checks and
balances to get right. (As Gene pointed out, what if they client crashes,
etc.).
MariaDb doesn't have an API for poking the clients; it's a database server
designed to respond to incoming requests. However, there is always a way :)
There is an API for writing your own extensions. You could hook up an
extension to fire on a database trigger. And that extension could be
designed to "poke" a registered client -- you'd have to think about what
protocols to use, how to get the message to VFP, how VFP would respond,
etc. If you had MariaDB running on a Windows-ish platform, it could likely
use DDE or OLE Automation (DCOM) to talk to a matching VFP app. Like I
said, lots of infrastructure, lots of edge cases to write error-trapping
for, managing stacks of callbacks, etc...
--- StripMime Report -- processed MIME parts ---
multipart/alternative
text/plain (text body -- kept)
text/html
---
[excessive quoting removed by server]
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/[email protected]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
