Comments on: DesignBais Tip - Getting Client Info http://Nebula-RnD.com/blog/general/2006/08/dbtip-clientinfo1.html Welcome to the Nebula Sun, 27 Jul 2008 02:00:04 +0000 http://wordpress.org/?v=2.2.2 By: sjdorst http://Nebula-RnD.com/blog/general/2006/08/dbtip-clientinfo1.html#comment-32 sjdorst Wed, 06 Sep 2006 15:08:08 +0000 http://Nebula-RnD.com/blog/general/2006/08/dbtip-clientinfo1.html#comment-32 Tony, I never envisioned that handling INCOMING calls could do without a process running on the client's desktop (whether it's a thick desktop or a desktop on a Windows Server accessed through a thin client.) There obviously has to be some process that responds to the incoming call notification and fires up the URL. Nice thing about DB vs Accuterm (what we're currently using, NOT the GUI) is that firing up another window doesn't take up another seat. As far as HOW this applet logs on to/establishes a connection with our phone system, we've got a few choices of communication path. TAPI is one (and you end up talking with the phone system's GUI client - Doesn't work unless the client is running, but this is actually a GOOD thing in our case, since we don't want a DB page to fire up UNLESS the user is logged into the phone system!) and there is another that connects directly to the server. I actually haven't done much research, just a general knowledge of what's necessary, with further refinements based on "Aha!" moments when people (such as yourself) talk about something that triggers an "Oh! That's how I can do this." thought. --Steve Tony,
I never envisioned that handling INCOMING calls could do without a process running on the client’s desktop (whether it’s a thick desktop or a desktop on a Windows Server accessed through a thin client.) There obviously has to be some process that responds to the incoming call notification and fires up the URL. Nice thing about DB vs Accuterm (what we’re currently using, NOT the GUI) is that firing up another window doesn’t take up another seat.
As far as HOW this applet logs on to/establishes a connection with our phone system, we’ve got a few choices of communication path. TAPI is one (and you end up talking with the phone system’s GUI client - Doesn’t work unless the client is running, but this is actually a GOOD thing in our case, since we don’t want a DB page to fire up UNLESS the user is logged into the phone system!) and there is another that connects directly to the server.
I actually haven’t done much research, just a general knowledge of what’s necessary, with further refinements based on "Aha!" moments when people (such as yourself) talk about something that triggers an "Oh! That’s how I can do this." thought.
–Steve

]]> By: Tony Gravagno http://Nebula-RnD.com/blog/general/2006/08/dbtip-clientinfo1.html#comment-31 Tony Gravagno Mon, 04 Sep 2006 01:44:45 +0000 http://Nebula-RnD.com/blog/general/2006/08/dbtip-clientinfo1.html#comment-31 <p>Sounds like you still need to work out another issue though. Unless you have the client polling the server you have no way of getting the call from the server to the end-user. There is the DBTIMER variable which will fire an After Display event on each timeout, and from there you can check to see if there is a call waiting, but this isn't appropriate for a real-time app. You can, however, load an executable on the end-user's PC which will respond to server events via mv.NET. This can fire up a browser instance to your DB app which the user can use to process the call. Really, it doesn't need to fire up a new browser instance, this component can be a thick container which displays a browser interface. It's a thin client within a thick client, so to speak, and can be deployed using SmartClient technology.</p> <p>Real-time processing of server-initiated transactions over the internet can be very tricky. There are issues with latency, security, deployment, and error handling. This won't be a slam-dunk. To make sure your end product is stable for various environments I think you're looking at a thicker solution than you had hoped.</p> Sounds like you still need to work out another issue though. Unless you have the client polling the server you have no way of getting the call from the server to the end-user. There is the DBTIMER variable which will fire an After Display event on each timeout, and from there you can check to see if there is a call waiting, but this isn’t appropriate for a real-time app. You can, however, load an executable on the end-user’s PC which will respond to server events via mv.NET. This can fire up a browser instance to your DB app which the user can use to process the call. Really, it doesn’t need to fire up a new browser instance, this component can be a thick container which displays a browser interface. It’s a thin client within a thick client, so to speak, and can be deployed using SmartClient technology.

Real-time processing of server-initiated transactions over the internet can be very tricky. There are issues with latency, security, deployment, and error handling. This won’t be a slam-dunk. To make sure your end product is stable for various environments I think you’re looking at a thicker solution than you had hoped.

]]> By: sjdorst http://Nebula-RnD.com/blog/general/2006/08/dbtip-clientinfo1.html#comment-30 sjdorst Sun, 03 Sep 2006 22:50:51 +0000 http://Nebula-RnD.com/blog/general/2006/08/dbtip-clientinfo1.html#comment-30 Yow! Passing the query string to DBW3CQSTRING is GREAT news! I've been thinking about how to get our MV app to RESPOND to an incoming call with caller ID through TAPI. Having the query string available solves half the problem. NOW all I need is an app sitting in the background that listens for incoming calls in TAPI, then when one with a caller ID number comes in, fire up an IE session to an appropriate URL with the number in the query string, then design the form (contact management) to pull up the contact (if only 1 found), choice of contacts (if more than 1 found) or create contact (if not found!) Yow! Passing the query string to DBW3CQSTRING is GREAT news! I’ve been thinking about how to get our MV app to RESPOND to an incoming call with caller ID through TAPI. Having the query string available solves half the problem.
NOW all I need is an app sitting in the background that listens for incoming calls in TAPI, then when one with a caller ID number comes in, fire up an IE session to an appropriate URL with the number in the query string, then design the form (contact management) to pull up the contact (if only 1 found), choice of contacts (if more than 1 found) or create contact (if not found!)

]]> By: Tony Gravagno http://Nebula-RnD.com/blog/general/2006/08/dbtip-clientinfo1.html#comment-29 Tony Gravagno Fri, 25 Aug 2006 07:57:56 +0000 http://Nebula-RnD.com/blog/general/2006/08/dbtip-clientinfo1.html#comment-29 <p>According to DBI today: "<font size="2">Version 4 will keep the users IP in DBSOURCEIP - you will also be able to pass a query string through to DBW3CQSTRING".</font></p> According to DBI today: "Version 4 will keep the users IP in DBSOURCEIP - you will also be able to pass a query string through to DBW3CQSTRING".

]]> By: symeonb http://Nebula-RnD.com/blog/general/2006/08/dbtip-clientinfo1.html#comment-23 symeonb Tue, 22 Aug 2006 13:52:47 +0000 http://Nebula-RnD.com/blog/general/2006/08/dbtip-clientinfo1.html#comment-23 Alternativley, you can use the approach already documented on here for file uploads (ie. you create a work variable and set  to html code to insert an iframe in your page with source of an asp or asp.net page on your IIS box and with the designbais session id passed in). The asp or asp.net code then needs to get the client ip address using request.ServerVariables("REMOTE_ADDR") and then use the filesystem object to write this to disk with an id of the designbais session id. Your Databasic can then read this in.rgdsSym. Alternativley, you can use the approach already documented on here for file uploads (ie. you create a work variable and set  to html code to insert an iframe in your page with source of an asp or asp.net page on your IIS box and with the designbais session id passed in). The asp or asp.net code then needs to get the client ip address using request.ServerVariables("REMOTE_ADDR") and then use the filesystem object to write this to disk with an id of the designbais session id. Your Databasic can then read this in.rgdsSym.

]]>