|
Aha! Found how to do it. One of the OleDbDataAdapter constructors allows you to pass in the max. # of rows to return. Works great.
And I have confirmed that "TOP n" is not valid "SQL" syntax for the MSIDXS OLEDB provider.
Great article, BTW, Heath.
-glenn-
|
|
|
|
|
Oh! Do you have a code-snipplet for me, please?
|
|
|
|
|
Sure, Martin. See below (sorry about the double spacing.) This code has been in production since April. See the DataAdapter object's Fill method to see how the maximum number of hits to return is passed to the OLEDB provider for Index Server. Since "TOP n" doesn't work with the query syntax that MSIDXS provides, our queries were running horribly slow. I forget where I found out about the DataAdapter parameter (although it was probably just scouring the docs - but the queries are lightning fast again.
-glenn-
------------------------------------------------------------
using System;
using System.Data;
using System.Data.OleDb;
using System.Diagnostics;
using System.Text;
using Company.Platform.IndexingService;
namespace Company.Platform.IndexingService
{
///
/// SearchCatalog an Indexing Service catalog using the OLEDB interface.
///
public class SearchCatalog
{
public static readonly string TableName = "SearchResults";
public static readonly string DataSetName = "SearchData";
public static readonly int DefaultMaxHits = 100;
public static readonly int MinMaxHits = 5;
public static readonly int MaxMaxHits = 500;
string _catalog;
int _maxHits;
const string _idxProvider = "MSIDXS";
OleDbConnection _conn;
public SearchCatalog(string catalogName)
: this(catalogName, DefaultMaxHits) {}
public SearchCatalog(string catalogName, int maxHits)
{
CatalogName = catalogName;
MaxHits = maxHits;
int connStringEstimate = 50;
StringBuilder connString = new StringBuilder(connStringEstimate);
connString.AppendFormat(
"Provider={0};Data Source={1};",
_idxProvider, /*{0}*/
CatalogName); /*{1}*/
// "Locale Identifier=nnnn;"
Debug.Assert(connString.Length <= connStringEstimate);
try
{
_conn = new OleDbConnection(connString.ToString());
}
catch (OleDbException e)
{
throw new DataException(
"Unable to connect to search catalog \"" +
CatalogName + "\".", e);
}
}
public string CatalogName
{
get { return _catalog; }
set { _catalog = value; }
}
public int MaxHits
{
get { return _maxHits; }
set
{
if (value < MinMaxHits || value > MaxMaxHits)
throw new ArgumentOutOfRangeException("MaxHits", value,
"Maximum Hits must be between " + MinMaxHits +
" and " + MaxMaxHits + ".");
_maxHits = value;
}
}
public DataSet GetDataSet(string query)
{
int hits;
return GetDataSet(query, out hits);
}
public DataSet GetDataSet(string query, out int hits)
{
// Remove any semicolons in the query string. This is to
// keep hackers from causing other SQL statements to
// execute.
query = query.Replace(";", string.Empty);
OleDbDataAdapter da = new OleDbDataAdapter(query, _conn);
DataSet data = new DataSet(DataSetName);
hits = 0;
try
{
_conn.Open();
hits = da.Fill(data, 0, MaxHits, TableName);
}
catch (OleDbException e)
{
if (e.ErrorCode == QueryCatalog.NoiseWordsOnly)
return null;
throw new DataException(
"Unable to execute search query \"" + query +
"\".", e);
}
finally
{
if (_conn != null && _conn.State != ConnectionState.Closed)
_conn.Close();
}
Debug.Assert(hits == data.Tables[TableName].Rows.Count);
return data;
}
}
}
|
|
|
|
|
Thank you very much.
So the solution should be:
hits = da.Fill(data, 0, MaxHits, TableName);
I've tried this some days ago, but it doesn't help. The problem is that regardless of "MaxHits" the whole result will be transmitted (as specified in the Framework SDK Documentation).
So I wonder why it works for you
My queries are lightning fast too as long as I get a relatively small resultset.
:'-(
Martin
|
|
|
|
|
Hey Martin. Could you expand on what you mean by 'The problem is that regardless of "MaxHits" the whole result will be transmitted (as specified in the Framework SDK Documentation).'
What do you mean by "transmitted"? That the DataSet ends up with all the matching hits for the query? That doesn't make sense to me because the documentation for the DbDataAdapter's Fill method says the parameter does this: "The maximum number of records to retrieve." It's also not what I observe in usage. If I specify 10 rows as the max to be returned, that's all the DataSet will have even if there are 10,000 potential hits. I guess that's why it works for me - Fill gets up to the maximum number of records specified and no more.
If I do not specify this parameter then the Index Server lookups slow to a crawl again (when looking up a word or phrase that has lots of hits, of course).
"My queries are lightning fast too as long as I get a relatively small resultset."
Well, sure. But of course we are trying to make the queries that can return lots of hits to run just as fast. The only way I know how to do this (even with the Index Server COM objects or with the ADO interface) is to limit the number of hits that can be returned.
-glenn-
|
|
|
|
|
Hi Glenn,
Well, the Documentation says that the DataSet contains the max number of hits. Nevertheless, the index server returns the whole resultset. Hmm, I don't know how I can explain it better with my poor english
I know, it sounds senseless that the index server returns the whole resultset even if you specify the maximum hit-count. But it explains why it doesn't solve my problem
So that's why I'm so interested in your solution (but there's no difference to mine, is it?).
It seems to be voodoo. But I can give you a code-snipplet from me (just ignore the german stuff):
--------- snip --------------
Public Function GetLimitedDataset(ByVal strsql As String, ByVal count As Integer) As DataSet
Dim myConnection As New System.Data.OleDb.OleDbConnection("Provider=MSIDXS;")
Dim mydap As New System.Data.OleDb.OleDbDataAdapter(strsql, myConnection)
Dim ds As New DataSet
'Die Anzahl darf nicht negativ sein
If count < 0 Then
count = 0
End If
Try
mydap.Fill(ds, 0, count, "Ergebnisse") 'count grenzt Treffermenge ein
Return ds
Catch
ds = Nothing
Return ds
End Try
End Function
--------- snip --------------
Do you have any ideas?
Martin
|
|
|
|
|
Upon closer inspection, the overloaded Fill() comes from System.Data.Common.DbDataAdapter (actually, that was evident from the docs...but I'm leading up to my point) and uses the max record count to only iterate through a DataReader so many times (for single and multiple result sets). It is not setting the DBPROP_MAXROWS property as I previously thought (this would've made since for any OLE DB provider that ADO.NET uses, which is the purpose for the classes in the System.Data.OleDb namespace). With this in mind, I see now reason why this wouldn't work - it is not functionality exposed by the OLE DB provider, it is simply an iterative loop with really no margin for error.
Have you verified that your count input is correct? Try Trace.WriteLine(count) or something and find out in your trace.axd file from your web app's root.
The only thing I can think of is how the connection is handled by IS's OLE DB provider. Typically, a DataReader reads results from the result of the DbCommand across the connection progressively. If, for some reason, the IS OLE DB provider would rather send the entire result set to the client and let it parse it, this could be causing the problem, but it works for glen, so I doubt this is the case.
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
"the overloaded Fill() [..] uses the max record count to only iterate through a DataReader so many times"
This makes sense, Heath, and would explain why lookups with a large number of hits ran faster using the "max hits" parameter - the DataReader only has to go to the source of the data that many times and not possible many, many more times.
I think you are also correct that Martin's count variable is probably incorrect (my money says it is accidentally set to 0).
I am also quite sure that you are correct about the behavior of the DataReader and that it asks for a row at a time until either (1) there are no more or (2) the "max hits" parameter value has been reached (so long as it is not set to 0 ).
-glenn-
|
|
|
|
|
There is another case...
When I rewrote all my old component-based code for accessing Index Server to .NET controls (pages, user controls, whatever), I never took this problem into account because I usually used my little toolkit on contractees with fewer pages (still in the hundreds, but nothing massive like MSDN Online!).
If this were the case, though, that you had so many files you really need to do this, it might be advantageous to use the Index Server <-> SQL Server "bridge". There is a way that SQL Server can access Index Server (using OPENROWSET ). Using this, you could schedule a task to read information from Index Server into a SQL database. Since SQL Server is a *real* database server and has many more optimizations I'm sure (not saying that IS is incredibly slow, just probably not as fast). This would also decouple your services somewhat and leave your IS open to, perhaps, scan an extremely large web site or even an entire network (perhaps for an Intranet site) while not slowing down results.
I admit it's somewhat of a silly idea, but it may warrant some research. If nothing else, you can use whatever T-SQL you like! Did a document find its way in there that shouldn't (perhaps your directory permissions or vdir assigning is correct), delete it! Need only a certain number of records, use ORDER BY. Need to find related documents by various PROPS of the resulting documents - use JOINS or recursive storedprocs. Remember, this is just an idea - perhaps not a very good one.
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
New to Index Server so this might not be a good lead as to what is up but...
I was unable to issue the "TOP n" clause while running SQLServer 7 (or better) and found that the database I was using was running in 6.5 compatibility mode. Changed the database to run in SQLServer 7 mode and was then able to use "TOP n".
Hope this helps.
Happy Trails,
Roderick...
rprince@radiaInteractive.com
Happy Trails,
Roderick...
rprince@radiainteractive.com
|
|
|
|
|
But there's no database associated with Index Server. Not a SQL database that is. To query an Index Server catalog you use a syntax that looks a lot like SQL but really isn't.
-glenn-
|
|
|
|
|
Actually, it is SQL. SQL stands for Structured Query Language and isn't strickly limited to databases anyway. In the case of Index Server, though, the OLE DB provider is providing access to Index Server but the OLE DB interfaces take care of most the parsing of the SQL, while the processing is split. This is why OLE DB is part of Microsoft's Universal Data Access initiative - to provide universal access.
So, it does use SQL, but may not support all the enhancements that other OLE DB providers (like the SQL Server driver) provide.
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
Alrighty. Let me put it this way. There are SQL standards for use with databases. Just because MS decided to call the syntax used to query Index Server's catalogs via OLEDB "SQL" does not make it a SQL language, much less a standard. But if you want to refer to Index Server catalog query language as "SQL", that's fine.
But enough of this. The last poster was claiming that upgrading or somehow using different versions of MS SQL Server effects how the "TOP n" syntax works with Index Server. It doesn't ("TOP n" doesn't work while querying an Index Server catalog using its OLEDB interface). In fact, SQL Server has nothing to do with Index Server's catalogs and you don't even need SQL Server installed on a system with IS catalogs!
-glenn-
|
|
|
|
|
Maybe you should try reading the docs. IS does use SQL with some extensions. SQL is not limited to a database. IS may not be SQL-92 compliant, but neither is MS Jet or other lower-grade databases - even found in the open source world. It would do you well to read[^].
Since the OLE DB provider is being used to access IS, most of the standard OLE DB properties exists, like DBPROP_MAXROWS. Setting this in the command object doesn't appear possible in .NET, however, but there may be some other way.
You can also limit the result size during binding. It will still get all the records found for matching docs, but a data-bound control like a DataGrid will only bind with so many records.
If you don't like this way, then use the IS objects like the Query obect, which has a MaxRecords properties defined on the object. You wouldn't get .NET's data-binding capabilities, but it'd work. If you wanted to use data-binding, you would have to create a DataSet manually from the recordset returned from Query.CreateRecordset . To get this recordset, you can do something like the following:
Type queryType = Type.GetTypeFromProgID("IXSSO.Query");
object query = Activator.CreateInstance(queryType);
queryType.InvokeMember("MaxRecords", BindingFlags.PutDispProperty,
null, query, new object[] {100});
object rs = queryType.InvokeMember("CreateRecordset", BindingFlags.InvokeMethod,
null, query, new object[] {"sequential"});
Its not very efficient, though, so you'll just have to decide what you want to do.
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
Heath, I think that you may be the one in need of reading the docs in this case. I'm pretty sure I've read everything in MSDN about Index Server at this point.
1. At best, the query syntax that MSIDXS supports is a subset of SQL. But I'm not going to argue the point anymore. All I'm trying to say is that the various "providers" for things like IS hardly deserve the distinction of being called SQL. Take the System.Management objects in .NET. They also have a very odd "SQL-like" syntax that I personally find very annoying to use. Maybe that's a good term to settle on? SQL-like. Fair enough?
2. DBPROP_MAXROWS is something you'd use with ADO. I prefer ADO.NET and one of the DataAdapter object's Fill methods has a parameter to specify the maximum number of rows to return. Prior to finding this, all the catalog lookups we were doing with ADO.NET returned all matches which you can imagine slowed the ASP.NET pages tremendously (depending upon the search phrase, of course).
3. Sure, you could limit the result set *displayed* during data binding, but the lookup would run just as slow no matter how many results are displayed or bound to a control. (I did try that technique early in my experimenting to rule out the possibility that binding the results to the control was not what was slowing things down - it was indeed the lookup.)
4. Prior to finding out about the Fill method's max. rows parameter I had indeed reverted back to creating interop wrappers for the Index Server DLLs (which is the interface we were using pre-.NET and pre-ADO.NET - in other words, with ASP). This was as fast as ever, but I didn't want to use COM wrappers. I did get the ADO recordsets returned by these objects to work in a DataSet. Which I thought was pretty cool, but a step backwards (we wanted to use as much of a "pure"/"native" ADO.NET implementation as possible).
The best bet if you are using .NET - particularly ADO.NET - is to trim the lookup via the Fill method's max. results parameter. See my previous reply from a few minutes ago showing a nice class I wrote to easily interface with Index Server catalogs. This code has been working great since April.
I didn't mean to ruffle any feathers in any of my replies. Truce?
-glenn-
|
|
|
|
|
I've spent about 6 years programming with IS and just as long with several major RDBMSes. You wanna argue with that? SQL is merely a language for manipulating data, commonly associated with databases. Databases usually support certain SQL standards like SQL-92 or SQL-95, but SQL IS ONLY A QUERY LANGUAGE! Read YOUR docs. Don't you even dare lecture me about programming. I've spent 15 years in the trade and have worked with many languages and APIs in great depth.
There is no "subset" of SQL, per se. There are different levels of compliance (or non-compliance) and each database server provides its own extensions, but SQL is not only for databases. It is a STRUCTURED QUERY LANGUAGE! Get a clue.
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
Look, son, I respectfully disagree. I've been a full-time professional programmer since 1976. And my reach extends far beyond simply MS technology (including programming various SQL databases since the early '80s). You top that!;P
I really don't know what your beef is. I thought this discussion started off very civily, but you are letting it degrade into I don't know what (and I don't know why). People will not always agree with how you see and define technology and technological terms. That's just how it is. Just because you get all hot and bothered, reciting your number of years in the this field, and start writing in caps will not change my mind. Sorry. I am more easily swayed by discussions about the technology at hand including code samples and not comments like "read YOUR docs". I still think you wrote a great article, Heath, FWIW. And I'll lecture anyone about programming - it's in my nature.
Let's try to keep the personal comments out of this thread and focus on the topic at hand: how to specify the # of rows to return from Index Server lookup using ADO.NET. I've given the best way to do this with ADO.NET which apparently has helped out others. I've also given concrete production code to do this. If you take a look at the class I posted a few replies back I would sincerely appreciate hearing from you if agree this is or is not the best way to program MSIDXS via ADO.NET. That I'm happy to debate.
BTW, I'm not taking any of these comments personally and I hope that you aren't either. It's just technology and it's not worth getting all worked up about.
-glenn-
|
|
|
|
|
15 years ago, MS was crap and I worked a great deal with other technologies as well, including the C64, various *nix platforms, and lots of different technologies ranging from databases to operating systems to filesystems and shells, and, of course, many different application layers and interfaces. I've had my nose in about everything since I was young and when I research, I don't mess around with just reading the summary like they teach so many people in tech colleges and books these days. Once I scratch the surface, I dig deep until it festers and scars.
All I'm saying is that SQL is not *strictly* for databases. It is a query language that follows a certain structure. It is true that is mostly used for databases, but is not *only* for databases. Index Server has provided an OLE DB provider, just like SQL Server, Oracle, ODBC, etc. Each of these providers parse and interpret SQL. That is their function - check the OLE DB docs on providers and clients. You feed them SQL, they give you results (or don't if you're using DDL or something).
As far as passing the MaxRecords, it works because it is writing to the standard DBPROP_MAXROWS property. That's what OLE DB - another abstraction layer. If you give it a property it understands, it will use it. If you give it a property it doesn't understand, you make it understand in your provider. Since it can't be done in what little SQL Index Server uses, then this way is probably the only way possible without filtering the results after the fact.
BTW, I have no problems debating - I was a state champion and national qualifier in debate in high school a long time ago. What I don't like is when someone keeps saying I'm wrong without so much as a shred of evidence, which you have not provided.
Besides, even if you are right, remember that OLE DB is an abstraction layer (part of the UDA movement from Microsoft) that makes anything look like a database. With that in mind, using what SQL you can with the OLE DB provider *is* querying a database as far as the front-end goes. What IS does with it is up to the provider (or some level between that and IS).
So make no mistake, as long as you're talking to IS through OLE DB, you are talking to a database driver. That is what OLE DB and ADO.NET is all about.
So IS doesn't support most SQL? Did you play with MySQL much when it first was released? It didn't support very much of SQL either and didn't even meet SQL-92 standards if I remember right (and I'm not talking about any alphas or betas).
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
"I don't mess around with just reading the summary like they teach so many people in tech colleges and books these days. Once I scratch the surface, I dig deep until it festers and scars."
I hear you there. I am constanting studying, much to the chagrin of my wife. I am not happy until I know everything I can find out about a piece of technology I use. It's a curse.
"As far as passing the MaxRecords, it works because it is writing to the standard DBPROP_MAXROWS property. That's what OLE DB - another abstraction layer. If you give it a property it understands, it will use it."
Quite true (I never said anything different). That's why I pointed out the correct solution to doing lookups with ADO.NET is to pass the maximum number of hits desired to the Fill method. I had to find this on my own by digging deep "until it festers and scars".
"What I don't like is when someone keeps saying I'm wrong without so much as a shred of evidence, which you have not provided."
What the heck are you talking about? I think you need to re-read what has been written here. You are taking offense at something I have not done. I have supplied plenty of code "evidence".
"Besides, even if you are right, remember that OLE DB is an abstraction layer (part of the UDA movement from Microsoft) that makes anything look like a database."
I already knew this. That's why Excel, Index Server, the System.Management namespace, etc., can pretend to be a database even though they aren't. Not in the sense that SQL Server, Oracle, SyBase, etc., are. And the Excel, Index Server, etc., OLEDB providers don't speak SQL as do a real database does.
"With that in mind, using what SQL you can with the OLE DB provider *is* querying a database as far as the front-end goes."
Bingo! I'm glad we finally agree. This is exactly what I said a couple of replies back. The "SQL" that Index Server speaks is a subset of what a full SQL database can speak.
I'm not sure why you seem to take this observation personally. You may disagree with the distinction I am making between Index Server's SQL dialect and a real database's SQL dialect (like SQL Server, et al). But that doesn't mean you can say my distinction is wrong just I can't say (and never have said) that you not chosing to observe that distinction is wrong. I understand fully what you mean when you say Index Server takes a SQL query. You should be big enough to admit that the SQL it speaks is at best a very, very small subset of any of the SQL standards out there. That's my only point in this "what does 'SQL' mean" debate and it helps no one to reduce the number of rows placed in a DataSet by a lookup to Index Server via ADO.NET.
"So make no mistake, as long as you're talking to IS through OLE DB, you are talking to a database driver."
Well, that's a pretty loose definition of a database driver. You can write an OLEDB provider for any data source you want be it a real relational database, an Index Server catalog, or something that pokes and prods at Windows' in-memory information like the System.Management namespace does.
"That is what OLE DB and ADO.NET is all about."
Well, no, not really. Certainly a big part of ADO.NET is about real databases. But just as large a part has nothing to do with an actual database and more to do with disconnected data sets (that may or may not have actual an actual backing store), not to mention the massive support for XML which has nothing to do with actual databases. ADO.NET is called such because it can be thought of as the next version of ADO but it is so much more than the data access (UDA) technologies of ADO. ADO.NET is far more than just a database interface layer like ADO.
BTW, for the record, my 26-years of paid, professional programming experience does not include my experience between the years of 10 and 18 as 8 of your 15 years of experience do. I don't include those years with the Altair 8800, Sinclair, PDP-11s, etc., in my official 26 year count since I was only paid a pittance prior to the age of 18.
Would you like to hear about my hiking experience as well?
-glenn-
|
|
|
|
|
I have always agreed that IS's SQL is a small subset, stating that it is by no means compliant with any standard, but it is still SQL. SQL is only a syntax, if you will, and IS, WMI, et. al. use it.
But, an OLE DB's provider is to provide database-like access. This *is* the whole purpose of OLE DB. I never stated that the backend of those drivers are databases, but the front-end - at least to the client - is a database. You can use (mostly) the same commands and properties no matter what you specify as the driver, be it SQL Server, Oracle, Index Server, WMI, or whatever (actually, does WMI even have an OLE DB provider - I know that some of the automation objects accept SQL). When you *use* ADO.NET, you are a client accessing the front-end of an OLE DB provider through ADO.NET - hence, that is why Index Server *acts* as a database. You give it a query in a syntax / language known as SQL.
During this debate, all you've kept saying is that Index Server does not use SQL, or that it isn't "real" SQL. As I kept saying, I have never denied that it is compliant with any standards, just that it uses SQL, which is really nothing more than a syntax. Standards and RDBMSes provide support for the various statements, functions, operators, predicates, etc.
As far as professional experience goes, I know a lot of "professionals" that don't know their ass from a hole in the ground. When I was in college, a small handful of us were teaching our professors. I worked for and with several people that even had Ph.D.s in Computer Science or Computer Engineering and didn't know anything about technologiy within the past one or two decades - pretty much full of historical knowledge that may teach us a lesson but has no other relevence besides that today.
I'm not saying you fall under this category, it's just that I don't put much stock in your 26 years of professional, paid experience (BTW, I have 10 - I was actually paid well as a kid because in my "large-yet-small" hometown there was only two of us that really knew this stuff...seriously).
And, no, I don't want to compare hiking experiences. I am an Eagle scout and did a lot of it myself in one of the most active troops in America that's now full of panty-wastes from overly liberal parents that think kids should be protected from *everything*. I do plan on taking my wife either this year or next for an extended hiking trip, who is also not so happy that my nose is usually buried in docs on the computer or that I spent 60+ hours a week at work.
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
"During this debate, all you've kept saying is that Index Server does not use SQL, or that it isn't "real" SQL. As I kept saying, I have never denied that it is compliant with any standards, just that it uses SQL, which is really nothing more than a syntax. Standards and RDBMSes provide support for the various statements, functions, operators, predicates, etc."
Well, no again; that is not all I have been saying. OK, I'll call what Index Server uses SQL as well if you will agree that it is a very, very small subset of *any* standard SQL and also extends any known SQL standard with incompatible keywords. Let me try to phrase my point this way: if someone writes a C# compiler that implements a tiny subset of the language's grammar and adds some incompatible extensions, would you still call that compiler a "C# compiler"? That's all I'm trying to say. Syntaxes don't just exist in a vacuum; they are embodied in standards. Without a standard there's no syntax to be discussed. Hence my preferred term of SQL-like just as the hypothetical compiler I mentioned would be C#-like. Would you at least admit that I have a point here?
My primary thrust throughout this thread has been how to speed up Index Server lookups via ADO.NET and I think I solved that one with the Fill method.
"it's just that I don't put much stock in your 26 years of professional, paid experience"
Now that's just plain silly. Spoken just like a true 25-year-old. Hey, reminds me of myself!
"troops in America that's now full of panty-wastes from overly liberal parents that think kids should be protected from *everything*."
Now you're talking; I couldn't agree more! But that's a different topic for a different forum.
It's been fun, Heath. I still like your article and I'm glad we've made it to the same page.
-glenn-
|
|
|
|
|
Yes, I do agree that syntax does not make a compliant language, but I never said that the SQL the IS OLE DB provider accepts is compliant. Heck, if you want to argue that, neither is ODBC's OLE DB provider (or rather, just OLE DB itself). There's a lot of incompatibilities for ya'. In any case, I do agree that it's a subset of any compliant SQL to date.
No, I don't think what I said was too entirely silly. While I said what I did originally because most people on CP are only beginning programmers (many of whom don't know how to hit F1, read the docs, or translate from one syntax to another using the same class library (i.e., my C# example to VB.NET), I don't completely agree that knowledge learned long ago will always apply. I'm not arguing you're not a smart person, just that some stuff so old doesn't really matter. For example, those first few years where spent typing:
10 LOAD 0,1
20 RUN
Fortunately, that knowledge means diddly now (except it makes for a great signature!). My mother has been calculating for years as a scientist but some of the tools she used back then - such as a slide rule - don't mean anything now. Some do.
Besides, my statement wasn't so much directed at you - I'm just trying to make a point. My old CEO for a internet-filtration and instrusion-detection company has been doing network security for years but knows nothing of modern-day (i.e., last decade or so) infrastructures like public-key encryption or network operating systems that aren't a major flavor of UNIX. I respect his knowledge, but most just isn't relevent today because it's been completely replaced by new technologies.
Also, I don't account my hot-headedness for being 25 - most people my age are still out geting trashed on a biweekly (if not more) basis at the bars while I do something constructive with my life. I'm just a very outspoken individual...and Irish-German.
I think we can both agree that either IS should support other statements like ORDER BY and DISTINCT , or that the OleDb classes of ADO.NET should honor the DBPROP_MAXROWS property (among others) since using a DataReader seems 1) inefficient, and 2) stupid because its not using much of the OLE DB driver (a lot of ADO interfaces are used in System.Data.Common , but much is just managed wrappers for other managed code). Preferably, I'd like to see both happen.
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
Like I said - you remind me of myself at 25. You should save what you write in CP somewhere and then re-read it in 20 years. Until then, you cannot understand my first sentence. This is not to say I don't have a lot of growing up to do - but I know that I do.
"I think we can both agree that either IS should support other statements like ORDER BY and DISTINCT, or that the OleDb classes of ADO.NET should honor the DBPROP_MAXROWS property (among others)"
I don't think I'd agree with that. I think that the syntax that Index Server supports right now is sufficient to do what it needs to do. There's no need to make Index Server a "real database".
"using a DataReader seems 1) inefficient, and 2) stupid because its not using much of the OLE DB driver"
The DataReader is the fastest way to read data from a data source using ADO.NET. And I suspect that Index Server is using all of the MSIDXS OLEDB provider features that are available. There just aren't many because there doesn't need to be for Index Server's purposes.
"(a lot of ADO interfaces are used in System.Data.Common, but much is just managed wrappers for other managed code)."
Except that the System.Data.Common namespace has nothing to do with ADO. ADO.NET can be thought of as the next evolutionary version of ADO but it really has nothing to do with the existing ADO code base; it's a whole new beast apparently written from scratch.
And what does "much is just managed wrappers for other managed code" mean? Did you mean "managed wrappers for unmanaged code"? If so, that's not the case with ADO.NET.
And the beat goes on...
-glenn-
|
|
|
|
|
Actually, if you look at the IL for the System.Data assembly, you'll see that you are definitely wrong there. Most of the ADO interfaces (unmanaged) are reflected in the assembly, such as IRowset, ICommand, and many others. Yes, most of the code is managed code, but a lot of interop goes on within the internals of the assembly. ADO.NET wraps some of the functionality of ADO by typecasting to managed reflections of unmanaged interfaces. When you typecast, the CCW performs a QI on the object. Now you have managed access through a managed interface to an object of unmanaged origins.
So, what I meant by my last statement is that ADO.NET classes use a lot of other ADO.NET classes (you wouldn't believe the foo going on when you simply call OleDbDataAdapter.Fill ) but they boil down to some interoping with ADO - after all, the OLE DB drivers (when used) need to be accessed and they are COM. This probably isn't the case (I don't feel like looking, although I have covered a lot of SqlClient IL before) with SQL Server- and Oracle-specific clients, but the classes and interfaces I'm referring to are actually in System.Data.Common , not System.Data.OleDb . All the classes in the latter namespace are just subsclasses or wrapper classes for those in the former namespace that do use ADO at some points.
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
Right, System.Data uses interop to get at a few ADO objects. But you said System.Data.Common in your post, not System.Data. If you meant System.Data then that makes a lot more sense.
The ADO.NET SQL, Oracle, etc. stuff is all brandy-new; only the OLEDB classes interop with ADO. (But we all knew that!)
And I assume that your statement "much is just managed wrappers for other managed code" is also a typo and you meant "much is just managed wrappers for unmanaged code". If so, only in the OLEDB classes is "much" correct; I believe that all of the other namespaces/classes are new managed code.
Lastly, let me ammend my statement: "ADO.NET can be thought of as the next evolutionary version of ADO but it really has nothing to do with the existing ADO code base; it's a whole new beast apparently written from scratch." By adding this sentence: Except for the OLEDB classes which interop with ADO to make ADO look like the ADO.NET model (which is quite different than the ADO model).
It's all smoke and mirrors. But keep in mind that ADO.NET is no ADO.
-glenn-
|
|
|
|
|