Brian/Jim
This approach *does* work. And, you don't need CF at the remote
(web) site... it can be any system/language which supports WDDX.
ASP/VBS, for example.
I have implemented a similar approach when migrating a site from one
App server/SQL Server Combo to a different App server/SQL Server.
It works like this:
You write a WDDX stub in ASP or CF, etc, that resides at the remote site.
You write a calling program to reside on the Local site.
The interaction of the two is described below,
I have mainly used this as a migration tool... I have not tried to
maintain concurrent copies of the databases (perform
updates/inserts/updates) at both sites.
By adding CFTransaction commands (or the equivalent) at the remote
site, the data integrity should be assured.
In this scenario, you could modify the Local programs to:
update the local database
perform the same update against the remote database via the stub mechanism
However, I get back to my original question... why not just have 1
web-centric database?
Dick
<!--- ------------------------------------------------------------- --->
<!--- This is a general-purpose routine that is called by another --->
<!--- program (presumably on a different host). This routine is --->
<!--- passed form fields which contain a SQL DSN, UserName, --->
<!--- Password, and SQL Statements. The SQL Statements are --->
<!--- contained in a WDDX packet to eliminate the need to handle --->
<!--- any special characters likely present. --->
<!--- --->
<!--- The SQL Statements are deserialized, and an SQL Query is --->
<!--- constructed and then executed. --->
<!--- --->
<!--- The Query Results are then serialized into another WDDX --->
<!--- packet which is returned to the calling program --->
<!--- --->
<!--- In effect, the Calling Program has a Query Results record set --->
<!--- available to it, as if the Query had been executed within the --->
<!--- program itself, rather than by a different Program on a --->
<!--- Remote Server. --->
<!--- --->
<!--- This is particularly useful when migrating a database from --->
<!--- one server to another, where programs on either server do --->
<!--- not have direct access to databases on the other. --->
<!--- --->
<!--- This program is written in Cold Fusion, but the equivalent --->
<!--- could easily be written in ASP, Perl, Java, C++ or any other --->
<!--- language which has access to SQL ODBC databases and WDDX --->
<!--- functions. --->
<!--- --->
<!--- In all likelihood, the calling program will be written in --->
<!--- Cold Fusion (although this is not a requirement). Cold --->
<!--- Fusion has a powerful facility, CFHTTP, which allows a --->
<!--- program to invoke programs on other servers and harvest their --->
<!--- output. --->
<!--- --->
<!--- ------------------------------------------------------------- --->
<!--- --->
<!--- A typical Calling Program: --->
<!--- --->
<!--- (Interactive Query Utility against a remote site) --->
<!--- --->
<!--- <!--- ---------------------------------------- ---> --->
<!--- <!--- Setup The User's Query ---> --->
<!--- <!--- ---------------------------------------- ---> --->
<!--- --->
<!--- <cfset TargetQuery = "#FORM.SQL_Input#"> --->
<!--- --->
<!--- <!--- Serialize the query into a WDDX Packet---> --->
<!--- --->
<!--- <cfwddx --->
<!--- Input="#TargetQuery#" --->
<!--- Action="CFML2WDDX" --->
<!--- Output="WDDX.SQLStatements"> --->
<!--- --->
<!--- <!--- Pass the Query to The Target Server Stub ---> --->
<!--- --->
<!--- <cfhttp URL="http://www.RemoteServer.com/ThisProgram/cfm" --->
<!--- METHOD="POST"> --->
<!--- <cfhttpparam --->
<!--- NAME=Datasource --->
<!--- VALUE="TargetDataSource" TYPE=FormField> --->
<!--- <cfhttpparam --->
<!--- NAME=UserName --->
<!--- VALUE="TargetUsername" TYPE=FormField> --->
<!--- <cfhttpparam --->
<!--- NAME=Password --->
<!--- VALUE="TargetPassword" TYPE=FormField> --->
<!--- --->
<!--- <!--- *** NOTE: The SQLStatement Field Must be URL --->
<!--- Encoded because it contains Special Characters ---> --->
<!--- --->
<!--- <cfhttpparam NAME=SQLStatements --->
<!--- VALUE="#URLEnCodedFormat(WDDX.SQLStatements)#" --->
<!--- TYPE=FormField> --->
<!--- --->
<!--- </cfhttp> --->
<!--- --->
<!--- ------------------------------------------------------------- --->
<!--- --->
<!--- Upon completion of the CFHTTP tag, the SQL Query Results are --->
<!--- available in a WDDX Packet contained in the --->
<!--- #CFHTTP.FileContent# variable. --->
<!--- --->
<!--- ------------------------------------------------------------- --->
..
..
..
Stub SQL Query Program
=========================================================================
=========================================================================
At 11:35 AM -0500 2/24/01, Brian Panulla wrote:
>Jim,
>
>Do both sites run ColdFusion? One possibility that I've been kicking around
>is using CF's WDDX to exchange data between servers via CFHTTP calls.... I
>think this model would work:
>
>1) "Extranet" server receives new listing from local LAN users.
>2) Listing is inserted into local LAN database
>3) Build new listing into an XML packet with CF's WDDX
>4) Transfer new listing to a special Web page on Public site via
>CFHTTP, which deserializes the XML and inserts the listing into the public
>system database.
>
>(include some try/catches to make sure the handshake operates properly)
>
>Now, this sounds a heck of a lot easier than SQL Replication, and if you
>only need to basically keep a handful of table up to date, this is the way
>to go.
>
>HOWEVER, I haven't yet done this myself. This is just a theory, so I can't
>guarantee my understanding of WDDX/XML is perfect.
>
>If you do wind up doing this, let me know... I'd love to hear how it
>works out.
>
>Brian
>
>At 9:10 PM -0700 2/23/01, Jim McAtee wrote:
> > >I've got the following situation:
> > >
> > >A real-estate company wants us to develop a suite of browser based
> > >applications for managing listings, client contact management, billing,
>etc.
><snip>
>
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
