<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:21636327;
mso-list-template-ids:-1128373934;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1
{mso-list-id:71129178;
mso-list-template-ids:2012801252;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l1:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2
{mso-list-id:1949576725;
mso-list-template-ids:1137848302;}
@list l2:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3
{mso-list-id:2021882659;
mso-list-template-ids:-1927483436;}
@list l3:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='color:#1F497D'>Hi,<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>To return FDO class from any SQL
will require extra processing from provider. This processing will in best case
add unnecessary overhead to provider.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>My suggestion is to enable
application to get info about returned columns trough feature readers. Same way
as non-fdo applications are doing it right now.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>I don't see any advantage in
trying to squeeze SQL statement result into FDO class and I can see many
problems there.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>Even opposite, I would prefer to
optimize FDO commands. Instead trying to guess what type of SLQ statement
application has executed or parsing current FDO filters it would be better that
we would have very simple "query window of data" type of command in
FDO. That is something not directly related to this RFC but it is direction where
I think FDO could go. Less overhead and simpler commands for most usual tasks.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>Haris<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
fdo-internals-bounces@lists.osgeo.org
[mailto:fdo-internals-bounces@lists.osgeo.org] <b>On Behalf Of </b>Orest
Halustchak<br>
<b>Sent:</b> Thursday, June 25, 2009 3:17 PM<br>
<b>To:</b> FDO Internals Mail List<br>
<b>Subject:</b> RE: [fdo-internals] Use of SQL pass through<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><span style='color:#1F497D'>Hi,<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>There hasn’t been too much
feedback on this.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>Haris, for SQL selects, to
return data in a feature reader, we either can simply describe the results of
the select and produce a temporary fdo class for the reader or if the SQL
select happens to correspond cleanly to an existing feature class (e.g.
something as simple as select * from roads), then we can use that fdo class
instead. The goal is to make it easier for application developers that can use
either fdo selects or sql selects and process the results with a common reader.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>Anybody else have comments? I
know we got some feedback from Jackie.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>Thanks,<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>Orest.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
fdo-internals-bounces@lists.osgeo.org [mailto:fdo-internals-bounces@lists.osgeo.org]
<b>On Behalf Of </b>Greg Boone<br>
<b>Sent:</b> Thursday, June 04, 2009 11:39 AM<br>
<b>To:</b> FDO Internals Mail List<br>
<b>Subject:</b> RE: [fdo-internals] Use of SQL pass through<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><span style='color:#1F497D'>Hi Haris,<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>Can you provide some examples of
non-DDL use cases that would make the proposal too complex? I also feel we
should limit the discussion at this time to read only DML statements such as
Select.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>Greg<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
fdo-internals-bounces@lists.osgeo.org
[mailto:fdo-internals-bounces@lists.osgeo.org] <b>On Behalf Of </b>Haris
Kurtagic<br>
<b>Sent:</b> Thursday, June 04, 2009 5:41 AM<br>
<b>To:</b> FDO Internals Mail List<br>
<b>Subject:</b> RE: [fdo-internals] Use of SQL pass through<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><span style='color:#1F497D'>I would like to divide this and
answer in two parts.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>Part with Parameters direction is
something we need. As it is already written , mostly to be able to execute and
get results from stored procedures.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>About executing SQL statements
and trying to squeeze result of it inside FDO class/schema, I think it is too
complex and in my mind without chance to be successful. There is so many cases
in which it can't be done properly. If we are missing some info about result of
execution of SQL we could look into existing specs like ODBC and add those. I
agree FDO application should be able to get all necessary info about executed
SQL so app can be written in generic way but I don't see putting that info in
FDO class or reengineering sql etc.. I believe what can be done with api's like
odbc is ok for fdo api too.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>Haris<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
fdo-internals-bounces@lists.osgeo.org
[mailto:fdo-internals-bounces@lists.osgeo.org] <b>On Behalf Of </b>Orest
Halustchak<br>
<b>Sent:</b> Wednesday, June 03, 2009 3:28 PM<br>
<b>To:</b> FDO Internals Mail List<br>
<b>Subject:</b> [fdo-internals] Use of SQL pass through<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>Hi,<o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>I would like to solicit feedback, discussion, and
suggestions on requirements and issues that we are seeing with the
FdoISQLCommand which is used for the purpose of SQL pass through for some of
the RDBMS-based providers.<o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>Please see the discussion below.<o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>Thanks,<o:p></o:p></p>
<p class=MsoNormal>Orest.<o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:1.8pt;margin-right:12.0pt;
margin-bottom:0in;margin-left:0in;margin-bottom:.0001pt'><b><span
style='font-size:14.5pt;font-family:"Arial","sans-serif";color:black;
letter-spacing:-.2pt'>Enhanced SQL Command Support Discussion<o:p></o:p></span></b></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span
style='font-size:12.0pt;font-family:"Arial","sans-serif";color:black;
letter-spacing:-.2pt'>Overview<o:p></o:p></span></b></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>The FDO
API currently defines support for a SQL command that allows for pass-through
execution of SQL statements either through a non-query execution of the SQL
statement directly in the underlying Data Store, or through a query mechanism
that returns a simple data reader listing the properties returned as a result
of the SQL execution. The definition of the SQL command has remained fairly
static over the last number of releases as primary development efforts have
focused on extending other aspects of the FDO API, implementing new providers,
etc. However, requirements for change to the SQL command have accumulated for
us as RDBMS providers have implemented SQL pass through support and clients
have attempted to integrate use SQL pass through into their applications in a
seamless manner. While we generally expect applications to be using the generic
FDO Select and other commands using FDO expressions, application still need to
execute direct SQL against RDBMS-based providers on an exception basis for
things that cannot do through FDO. While we hope to improve the FDO expression
capabilities over time, there will always be this need for direct SQL
processing for exception cases.<o:p></o:p></span></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>This
email is meant to start discussion on how to handle the requirements that
we’ve been seeing and to get feedback on how to modify the FDO api to
handle these requirements. We have some ideas as described below, but would
like to get other feedback. We’ll draft an RFC once we get close to a
consensus on how it should look.<o:p></o:p></span></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span
style='font-family:"Verdana","sans-serif";color:black'>Requirements<o:p></o:p></span></b></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>One key
request has been the desire to have the FDO API support SQL pass-through
commands that return an FDO feature reader, referencing a proper FDO schema,
not simply an FDO data reader. The feature reader will contain proper geometry
properties, relations and associations. This enhancement is also intended to
allow client applications that use FDO Feature Readers to code their
applications in a generic manner so that data coming back from Select or SQL
Pass Through statements can be processed in a uniform manner, thus reducing
complexity, costs and time to implement. <o:p></o:p></span></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>Other
more SQL specific requirements related to this have also arisen, including: <o:p></o:p></span></p>
<ul type=disc>
<li class=MsoNormal style='color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:
auto;mso-list:l1 level1 lfo3'><span style='font-size:10.0pt;font-family:
"Verdana","sans-serif"'>A need to allow a client to set the size of the fetch
array an FDO provider will use when executing SQL statements ([OH] I still
have an issue with this one. Fetch sizes are internal tuning parameters
and are not FDO api concepts. Other providers that deal with select or
insert buffering have default internal sizes.)<o:p></o:p></span></li>
<li class=MsoNormal style='color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:
auto;mso-list:l1 level1 lfo3'><span style='font-size:10.0pt;font-family:
"Verdana","sans-serif"'>A need to specify bind variables for the SQL
command, including arrays of bind variables. Since SQL commands may
include stored procedure execution, bind variables need indication of
whether they are input, output, or return parameters.<o:p></o:p></span></li>
</ul>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span
style='font-size:12.0pt;font-family:"Arial","sans-serif";color:black;
letter-spacing:-.2pt'>Discussion<o:p></o:p></span></b></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>In
general, the intent of SQL pass-through is to deal with physical schemas. There
is no parsing of the SQL statements, and what are identified are physical
schema tables, columns, functions, commands, etc. The SQL statement can be any
SQL command, not just select, but any DML (select, insert, update, delete) or
any DDL (create, drop, alter, …). However, FDO feature readers deal with
FDO logical schemas, which is at a different conceptual level. It’s the
mixing of these levels that causes difficulty for applications using the FDO
API. Applications are required to use different code pathways to handle select
statement as opposed to direct SQL execution. If clients could use the result
of either of these types of operations in a generic routine or component, such
as a Data Table or Symbolization packages, applications would be provided a
much more seamless and dynamic mechanism on which they can build and extend
their applications. <o:p></o:p></span></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>To a
certain degree, the current FDO feature reader implementation assumes an FDO
class definition is directly related to the properties being returned. With
physical schema SQL (let’s say just Select command), there isn’t
necessarily any FDO class definition that applies. This is why currently the
SQL command's Execute method returns a data reader, which handles any
generically returned data. Note that the FDO select aggregates command
doesn’t return a feature reader either, since it’s returning
computed data. <o:p></o:p></span></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>One
response to this issue has been to suggest that providers reverse engineer the
select results and attempt to find the FDO class definition (coming from a
describe schema request) that matches it. Other suggestions have been to
construct a class definition on the fly, one that would not result from a call
to describe schema. If the select is from a single table, providers would find
the class definition that is based on that table and use it. However, then
matching up the columns being selected with the properties in the logical
schema, there may be some slight differences. This would result in the mixing
of physical schema and logical schema elements together. For example, class
names that are not the same as table names, property names that are not the
same as column names, the use of additional computed columns, inclusion of pkey
columns, etc. Granted that in many cases, the logical and physical views would
be virtually identical. However, since that cannot be guaranteed, the design
that is adopted will have to be able to handle the general case. <o:p></o:p></span></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>To
account for these scenarios, providers will need to be modified to reverse
engineer class definitions from the selected data and not attempt to match the
select request to an existing FDO class. In reality, FDO Providers will be
required to handle this in any case since a generic SQL select may not match up
at all with an existing FDO class. An example of this can be found when
selecting from a table with an owner that is different from the connected data
store. For example, Connect to data store called Denver and select from
Boulder.Roads – the schema may or may not be similar to Denver.Roads. In
these types of circumstances, providers should manufacture a new class
definition. <o:p></o:p></span></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>In
cases where the resulting columns come from an existing FDO feature table, a
provider can return the class definition corresponding to that table. In cases
where the columns come from an unknown table, a class definition can be
constructed on the fly. By definition, the FDO class definition returned by a
feature reader does not necessarily correspond exactly to an existing FDO class
definition. Existing class definitions may contain the properties that were
asked for in the Select command, plus additional computed properties. It is
perfectly legal to return a constructed class definition, which is only valid
for the select that was executed, and not usable for further updates or
inserts. <o:p></o:p></span></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>In the
circumstance that a computed class is generated, the FDO class
definition’s IsComputed property will return true. In this manner,
applications are able to distinguish the content of the feature reader
responses coming from the providers and tailor their implementation
accordingly. In such a situation, some care will also need to be given to the
name of the generated FDO schema and class definitions. At this point no
standards exist for naming auto-generated schema, class and property names. It
would be beneficial if, as a result of this RFC, some uniform naming
conventions could be adopted. <o:p></o:p></span></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>Providers
that do return feature readers from SQL commands will need to come up with the
appropriate class definition that the feature reader could expose. Here are a
few general use cases: <o:p></o:p></span></p>
<ul type=disc>
<li class=MsoNormal style='color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:
auto;mso-list:l0 level1 lfo6'><span style='font-size:10.0pt;font-family:
"Verdana","sans-serif"'>Select is against a table that has an existing
class definition and the select returns the same information as defined by
the class definition (e.g. select * from roads). <o:p></o:p></span></li>
<li class=MsoNormal style='color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:
auto;mso-list:l0 level1 lfo6'><span style='font-size:10.0pt;font-family:
"Verdana","sans-serif"'>Select is against a table that has an existing
class definition, but the select returns other information such as a
subset of properties or additional computed properties. The FDO select
command handles this type of case as well. The class definition returned
by the feature reader includes the specific properties for that select. <o:p></o:p></span></li>
<li class=MsoNormal style='color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:
auto;mso-list:l0 level1 lfo6'><span style='font-size:10.0pt;font-family:
"Verdana","sans-serif"'>Select is against a table that doesn’t have
an existing class definition. Providers will be required to generate a
temporary class definition. <o:p></o:p></span></li>
<li class=MsoNormal style='color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:
auto;mso-list:l0 level1 lfo6'><span style='font-size:10.0pt;font-family:
"Verdana","sans-serif"'>Select is against a table that has an existing
class definition, but the select is an aggregation that doesn’t
return actual objects (e.g. select count(*), max(length) from roads). In
this case it doesn’t make sense for the provider to return the same
class name as for the underlying table since it is not actually returning
road objects at all. This is basically another temporary class definition.<o:p></o:p></span></li>
</ul>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span
style='font-family:"Arial","sans-serif";color:black;letter-spacing:-.2pt'>FDO
API Ideas</span></b><b><span style='font-size:10.5pt;font-family:"Arial","sans-serif";
color:black;letter-spacing:-.2pt'><o:p></o:p></span></b></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>In
order to support the SQL pass-through objective outlined above, the FDO API
will need to be modified to provide a new capability function to state that
this is supported, and to provide a way to return an explicit FDO Feature
Reader. Two possibilities have been identified for returning the feature
reader. One idea is to add a new ExecuteFeatureReader (or similar name) method
to FdoISQLCommand. The existing ExecuteReader method will remain as is for
backwards compatibility. Another possibility is to keep the SQL pass through
interface unchanged but provide a utility that will convert the returned SQL
Data Reader into a Feature Reader after the fact.<o:p></o:p></span></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>A
related question is around the class definition that would be generated from
the SQL since it often would be a temporary class definition for the command
and not something found from the FDO Describe Schema command. The feature
reader would expose that class definition, but would applications need to get
that earlier, e.g. with a new method on FdoISQLCommand to describe the
generated class definition prior to getting the reader?<o:p></o:p></span></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span
style='font-size:12.0pt;font-family:"Arial","sans-serif";color:black;
letter-spacing:-.2pt'>Parameter Direction<o:p></o:p></span></b></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>FDO
already includes API’s for defining and using parameters (bind
variables). However, there is no indication of direction (input versus output)
and if an application is planning to use stored procedure calls in the SQL pass
through, they would need to provide some indication of input, output, or return
parameters. A possibility is to add a new FdoParameterDirection enumeration and
add set/get methods to the FdoParameterValue or FdoParameterValueCollection
interface.<o:p></o:p></span></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'>A
related question is whether FdoISQLCommand needs the application to tell it
whether the SQL command being executed is a stored procedure call or some other
type of SQL? We want to avoid having providers be forced to parse SQL where
currently they probably all just send the SQL directly to the underlying
server. The ExecuteNonQuery versus ExecuteReader methods that the application
uses already tell the provider whether to expect results back from the SQL or
not. A stored procedure call is a “non-query” but can return
results, so is it another case?<o:p></o:p></span></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif";color:black'><o:p> </o:p></span></p>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</body>
</html>