Discussion:
FSO or ADODB?
(too old to reply)
Roland Hall
2003-11-29 01:38:46 UTC
Permalink
Without referencing documented articles, what is your preference and why
would you use FSO, including XL vs ADODB to retrieve dynamic content? I
have read numerous articles that state a db is unnecessary overhead and/or
FSO is more complicated and requires extra programming for the same result.

Where have you found one vs the other to be beneficial and please provide
the particulars.
--
Roland

This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose.
Martin Honnen
2003-11-29 11:14:54 UTC
Permalink
Post by Roland Hall
Without referencing documented articles, what is your preference and why
would you use FSO, including XL vs ADODB to retrieve dynamic content? I
have read numerous articles that state a db is unnecessary overhead and/or
FSO is more complicated and requires extra programming for the same result.
Where have you found one vs the other to be beneficial and please provide
the particulars.
If FSO is the FileSystemObject then it is only helpful to read text
files from the file system. An ADODB.Stream however allows you to read
text and binary data from the file system and from a HTTP URL.
--
Martin Honnen
http://JavaScript.FAQTs.com/
Roland Hall
2003-11-29 20:41:54 UTC
Permalink
Hi Martin...

I think you misunderstood my question. I'm looking for preferences between
using ADODB (ActiveX Data Object) with a database and FSO (File System
Object) with a text file, excel file, etc? I should have mentioned I'm not
comparing ADODB.Stream to FSO.
Post by Martin Honnen
Post by Roland Hall
Without referencing documented articles, what is your preference and why
would you use FSO, including XL vs ADODB to retrieve dynamic content? I
have read numerous articles that state a db is unnecessary overhead and/or
FSO is more complicated and requires extra programming for the same result.
Where have you found one vs the other to be beneficial and please provide
the particulars.
If FSO is the FileSystemObject then it is only helpful to read text
files from the file system. An ADODB.Stream however allows you to read
text and binary data from the file system and from a HTTP URL.
--
Martin Honnen
http://JavaScript.FAQTs.com/
Bob Barrows
2003-11-29 20:52:51 UTC
Permalink
Post by Roland Hall
Without referencing documented articles, what is your preference and
why would you use FSO, including XL vs ADODB to retrieve dynamic
content? I have read numerous articles that state a db is
unnecessary overhead and/or FSO is more complicated and requires
extra programming for the same result.
Where have you found one vs the other to be beneficial and please
provide the particulars.
If you need a relational database, use a relational database. If you need a
flat file, use a flat file.

RDBMS's do a better job of searching, filtering, maintaining the data, along
with handling concurrency issues, than would ever be possible with a flat
file.

Bob Barrows
--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"
Roland Hall
2003-11-29 22:42:48 UTC
Permalink
Granted but I read that most DBs are being used, on the web, with single
tables or no relationships and arguments are that FSO would be less
overhead.
Post by Bob Barrows
Post by Roland Hall
Without referencing documented articles, what is your preference and
why would you use FSO, including XL vs ADODB to retrieve dynamic
content? I have read numerous articles that state a db is
unnecessary overhead and/or FSO is more complicated and requires
extra programming for the same result.
Where have you found one vs the other to be beneficial and please
provide the particulars.
If you need a relational database, use a relational database. If you need a
flat file, use a flat file.
RDBMS's do a better job of searching, filtering, maintaining the data, along
with handling concurrency issues, than would ever be possible with a flat
file.
Bob Barrows
--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"
Steve van Dongen [MSFT]
2003-11-30 00:21:52 UTC
Permalink
Post by Roland Hall
Post by Bob Barrows
Post by Roland Hall
Without referencing documented articles, what is your preference and
why would you use FSO, including XL vs ADODB to retrieve dynamic
content? I have read numerous articles that state a db is
unnecessary overhead and/or FSO is more complicated and requires
extra programming for the same result.
Where have you found one vs the other to be beneficial and please
provide the particulars.
If you need a relational database, use a relational database. If you need
a
Post by Bob Barrows
flat file, use a flat file.
RDBMS's do a better job of searching, filtering, maintaining the data,
along
Post by Bob Barrows
with handling concurrency issues, than would ever be possible with a flat
file.
Granted but I read that most DBs are being used, on the web, with single
tables or no relationships and arguments are that FSO would be less
overhead.
Whether you are using 1 table or 100 in your application is
irrelevant. The decision to use one or the other must be based
primarily on your business requirements. There may be other factors
as well such as the skill set of your developers and development time.

I find it hard to believe that all these articles you've read make
statements like those that you've mentioned with nothing to back it
up. If the author(s) truly didn't include any explanation of their
reasoning then you need to find a better source of information.

Bob has already given you a decent starting point on the reasons to
use a RDBMS. I'll add performance (indexing, caching, distributed
queries), aggregations/summarization, and interoperability with other
systems.

Regards,
Steve
--
Please post questions to the newsgroup; everyone benefits.
This post is provided "AS IS" with no warranties, and confers no rights
Sample code subject to http://www.microsoft.com/info/cpyright.htm
Roland Hall
2003-11-30 10:11:53 UTC
Permalink
I think you're missing the point. I'm not asking for theory. I'm asking
what YOU use in certain circumstances. I'm trying to get a handle on what
most people are using and why. That's all. My only application is
research.

Here is an example:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=OSvABeYXBHA.1408%40tkmsftngp05&rnum=2&prev=/groups%3Fq%3Dfso%2Bor%2Bado%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3DOSvABeYXBHA.1408%2540tkmsftngp05%26rnum%3D2

Here is another:
http://groups.google.com/groups?q=ado+or+fso+dynamic+content&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=e%23nw18X49GA.172%40uppssnewspub05.moswest.msn.net&rnum=1
Post by Steve van Dongen [MSFT]
Post by Roland Hall
Post by Bob Barrows
Post by Roland Hall
Without referencing documented articles, what is your preference and
why would you use FSO, including XL vs ADODB to retrieve dynamic
content? I have read numerous articles that state a db is
unnecessary overhead and/or FSO is more complicated and requires
extra programming for the same result.
Where have you found one vs the other to be beneficial and please
provide the particulars.
If you need a relational database, use a relational database. If you need
a
Post by Bob Barrows
flat file, use a flat file.
RDBMS's do a better job of searching, filtering, maintaining the data,
along
Post by Bob Barrows
with handling concurrency issues, than would ever be possible with a flat
file.
Granted but I read that most DBs are being used, on the web, with single
tables or no relationships and arguments are that FSO would be less
overhead.
Whether you are using 1 table or 100 in your application is
irrelevant. The decision to use one or the other must be based
primarily on your business requirements. There may be other factors
as well such as the skill set of your developers and development time.
Business requirements? Surely you jest. What if it is for personal use?
Why would I use a RDBMS if I only have one table?
Post by Steve van Dongen [MSFT]
I find it hard to believe that all these articles you've read make
statements like those that you've mentioned with nothing to back it
up. If the author(s) truly didn't include any explanation of their
reasoning then you need to find a better source of information.
Bob has already given you a decent starting point on the reasons to
use a RDBMS. I'll add performance (indexing, caching, distributed
queries), aggregations/summarization, and interoperability with other
systems.
Regards,
Steve
--
Please post questions to the newsgroup; everyone benefits.
This post is provided "AS IS" with no warranties, and confers no rights
Sample code subject to http://www.microsoft.com/info/cpyright.htm
Bob Barrows
2003-11-30 12:16:55 UTC
Permalink
In that case, I use flat files (actually xml files) for things like static
lookup data. Data that rarely changes: company master, department master,
user security settings, etc. It is a big plus to cache this type of data on
the web server and save a trip to the database. If the list is small enough,
I will store it in an Application variable as a free-threaded XML Document.

If data maintenance is to be involved, especially by more than one user at a
time, I will opt for the database. No contest.

HTH,
Bob Barrows
Post by Roland Hall
I think you're missing the point. I'm not asking for theory. I'm asking
what YOU use in certain circumstances. I'm trying to get a handle on what
most people are using and why. That's all. My only application is
research.
--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"
Bob Barrows
2003-11-30 12:34:55 UTC
Permalink
I should add that even though I'm caching this type of data on the web
server in flat files, the source of the data is almost invariably a database
table, because this type of data is almost invariably used in data
relationships. I can think of only one or two instances where I stored data
on the web server without storing the source of the data in the database.

Bob Barrows
Post by Bob Barrows
In that case, I use flat files (actually xml files) for things like
static lookup data. Data that rarely changes: company master,
department master, user security settings, etc. It is a big plus to
cache this type of data on the web server and save a trip to the
database. If the list is small enough, I will store it in an
Application variable as a free-threaded XML Document.
If data maintenance is to be involved, especially by more than one
user at a time, I will opt for the database. No contest.
HTH,
Bob Barrows
Post by Roland Hall
I think you're missing the point. I'm not asking for theory. I'm asking
what YOU use in certain circumstances. I'm trying to get a handle on what
most people are using and why. That's all. My only application is
research.
--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"
Roland Hall
2003-11-30 18:18:19 UTC
Permalink
Thanks Bob, good answer.

Two questions:
1. Is all of your development in this area business related?
2. You state most of what you do is with a database. Is this always a SQL
database?
Post by Bob Barrows
I should add that even though I'm caching this type of data on the web
server in flat files, the source of the data is almost invariably a database
table, because this type of data is almost invariably used in data
relationships. I can think of only one or two instances where I stored data
on the web server without storing the source of the data in the database.
Post by Bob Barrows
In that case, I use flat files (actually xml files) for things like
static lookup data. Data that rarely changes: company master,
department master, user security settings, etc. It is a big plus to
cache this type of data on the web server and save a trip to the
database. If the list is small enough, I will store it in an
Application variable as a free-threaded XML Document.
If data maintenance is to be involved, especially by more than one
user at a time, I will opt for the database. No contest.
HTH,
Bob Barrows
Bob Barrows
2003-11-30 19:30:35 UTC
Permalink
Post by Roland Hall
Thanks Bob, good answer.
1. Is all of your development in this area business related?
Yes
Post by Roland Hall
2. You state most of what you do is with a database. Is this always
a SQL database?
Almost always. I did a quickie one-off once with Access, after making clear
to the people requesting it that using Access would limit its scalability.

Bob Barrows
--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"
Steve van Dongen [MSFT]
2003-11-30 13:51:32 UTC
Permalink
Post by Roland Hall
I think you're missing the point. I'm not asking for theory. I'm asking
what YOU use in certain circumstances. I'm trying to get a handle on what
most people are using and why. That's all. My only application is
research.
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=OSvABeYXBHA.1408%40tkmsftngp05&rnum=2&prev=/groups%3Fq%3Dfso%2Bor%2Bado%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3DOSvABeYXBHA.1408%2540tkmsftngp05%26rnum%3D2
http://groups.google.com/groups?q=ado+or+fso+dynamic+content&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=e%23nw18X49GA.172%40uppssnewspub05.moswest.msn.net&rnum=1
I don't use flat files. I do however ocassionally use XML files for
small amounts of static data like config files that I load into an XML
DOM. I use databases for everything because of the amount of data
and/or features noted previously by Bob and I.

Regards,
Steve
--
Please post questions to the newsgroup; everyone benefits.
This post is provided "AS IS" with no warranties, and confers no rights
Sample code subject to http://www.microsoft.com/info/cpyright.htm
Roland Hall
2003-11-30 18:29:49 UTC
Permalink
Thanks Steve.

Two questions:
1. Is all of development in this area business related?
2. You state you never use flat files. How do you work with image files?

Other than preloading from disk, do you ever have an application to store
them in a database, as a blob I think it is? I've heard mixed views and it
sounds like a waste of resources to me.

My original question should have referenced XML since I believe it was XLM
vs ADODB that I was reading about and articles had stated that XML was more
efficient than visiting the database. I'm sure the application is a factor
as you and Bob have stated.
Post by Steve van Dongen [MSFT]
I don't use flat files. I do however ocassionally use XML files for
small amounts of static data like config files that I load into an XML
DOM. I use databases for everything because of the amount of data
and/or features noted previously by Bob and I.
Regards,
Steve
Steve van Dongen [MSFT]
2003-12-04 18:37:22 UTC
Permalink
Post by Roland Hall
Thanks Steve.
1. Is all of development in this area business related?
2. You state you never use flat files. How do you work with image files?
Other than preloading from disk, do you ever have an application to store
them in a database, as a blob I think it is? I've heard mixed views and it
sounds like a waste of resources to me.
My original question should have referenced XML since I believe it was XLM
vs ADODB that I was reading about and articles had stated that XML was more
efficient than visiting the database. I'm sure the application is a factor
as you and Bob have stated.
Post by Steve van Dongen [MSFT]
I don't use flat files. I do however ocassionally use XML files for
small amounts of static data like config files that I load into an XML
DOM. I use databases for everything because of the amount of data
and/or features noted previously by Bob and I.
1. Yes.
2. Yeah, I use images. I'm only talking about textual data. Images
aren't particularly relevant in a discussion of FSO vs. ADO because
FSO only supports text files.
--
Please post questions to the newsgroup; everyone benefits.
This posting is provided "AS IS" with no warranties, and confers no rights.
Sample code subject to http://www.microsoft.com/info/cpyright.htm
Julian Turner
2003-12-04 14:11:27 UTC
Permalink
Sorry if this a late posting.

If it is of interest to you, I am a hobby progammer, and
have been wrestling with FSO and ADODB myself.

I am in the process of teaching myself ADODB and MySQL,
which seem to be necessary for any substantial database
implementation.

However I have found FSO and flat file useful for simple
look up XML databases.

I guess the problem you have with flat files is that if
you have lots of users accessing the web site, then each
user's session will be loading the flat file separately,
which has a memory load on the server I suspect.

As I am using SUN's ASP server, it does not as far as I am
aware come with a free threaded XML ActiveXObject for
javascript. This has meant that I cannot store the XML
document in an Application object to share the memory load
(there are apartment threading issues if you use JScript
Object).

Therefore, necessity being the mother of invention, I have
developed my own lightweight JScript XML engine to process
requests to the XML flat file. This engine does not need
to parse the whole document, therefore reducing memory
load on the server. But it does mean that the flat file is
loaded separately for each Session.

See www.baconbutty.com/Recip.htm, where both the index
tree and text are dynamically loaded from the server when
you request them. I use a client side XML object to make
hidden calls to the server:-

var oXML=new ActiveXObject("MSXML.DOMDocument");
oXML.async=false;
oXML.load("http://www.baconbutty.com/request.asp?
Function=GetRecord&Database=recipies.xml&RecordNumber=12");

Hope this is of interest.
-----Original Message-----
Without referencing documented articles, what is your
preference and why
would you use FSO, including XL vs ADODB to retrieve
dynamic content? I
have read numerous articles that state a db is
unnecessary overhead and/or
FSO is more complicated and requires extra programming
for the same result.
Where have you found one vs the other to be beneficial
and please provide
the particulars.
--
Roland
This information is distributed in the hope that it will
be useful, but
without any warranty; without even the implied warranty
of merchantability
or fitness for a particular purpose.
.
Loading...