Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
XMLTOCURSOR too slow
Message
From
07/12/2001 09:59:30
 
 
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Miscellaneous
Thread ID:
00589312
Message ID:
00591132
Views:
23
"I think that the need to use XML here is poorly thought out"

Not so much poorly thought out as working with bad information. I had never tried to use XML before and everyone was saying such good things about it that I thought it would work for passing data between objects. I just didn't know until I got too far into things that it's not good for that.

Now I know, and in the new thread I started, I got lots of wonderful advice on how to do things better. It's hard jumping into this when I've been dealing with SBT code for so long, but I'll get the hang of it.

Thanks for the post; very interesting reading. And congrats on the doctorate.

Michelle


>I think that the need to use XML here is poorly thought out; while the use of XML is appropriate to passing data between tiers, it's unnecessary when the tiers are coresident in a common file system. Rather than creating a cursor, converting the cursor to XML, passing the XML, and reconverting to a cursor, if the file systems are coresident and compatible, a simpler mechanism would be to pass a file reference between tiers, and the transport overhead is now minimized. Rather than requiring the transport of the data, we now transfer the common reference to the data, reducing the transport cost to the cost of transporting the location of the data in the form of a common file name - it can be an absolute local file reference, a UNC if a common file system is in use, or a URL if a common virtual filesystem exists. In the case of moving around a cursor, I'd assume a common file system existed, and use logic along the lines of:
>
>
<i>Create a cursor</i>
>lcCursorFileName = FULLPATH(DBF())
>DECLARE INTEGER WNetGetConnection IN WIN32API STRING @ lpLocal, STRING @ lpRemote, INTEGER @ lpnLength
>LOCAL lcCursorFileName, lcPassedFilename, lcBuffer, lnLength
>IF LEFT(lcCursorFileName,2) = '\\' && It's a UNC, so it can be passed
>   lcPassedFileName = lcCursorFilename
>ELSE
>   lcBuffer = REPL(CHR(0),262)
>   lnLength = 262
>   IF WNetGetConnection(LEFT(lcCursorFileName,2),@lcBuffer,@lnLength) = 0
>      lcPassedFileName = ADDBS(CHRTRAN(lcBuffer,CHR(0),'')) + SUBST(lcCursorFilename,4)
>   ELSE
>      && not on a share, so it has to be moved to another shared file system
>      && location, and the new location passed in lcPassedFileName
>   ENDIF
>ENDIF
>
>This now passes the reference, the shared filesystem serves as the transport mechanism, and the overhead is minimal. If the data does not reside on a common file system, then the data has to reside in a commonly referencable location, and the reference is passed across the layers.
>
>This is not foolproof; it assumes that the data handlers on either side of the interface know how to handle the common file; that the processes on both sides have equivalent rights and permissions to the shared reference point, and there may be consequences to having to move the file to a common reference point from where it gets created initially. Also, it's relatively easy to safely represent hierarchical and network data structures in an XML format, and file system issues are avoided. However, the bulkiness of the data transfer, not to mention the marshalling cost enforced by using XML transport across layers (it costs a whole lot more to move an entire file than the name of a file when all you do is pass it along without examining the data) is avoided.
>
>It works in a moderately homogeneous environment with shared resources pretty well; when file format and data format considerations across platforms become an issue, you have to pay the piper and move the data in a commonly-agreed form such as XML rather than exchange references.
Previous
Reply
Map
View

Click here to load this message in the networking platform