By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,664 Members | 1,986 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,664 IT Pros & Developers. It's quick & easy.

HTML and XML

P: n/a

I currently use the MS-Access automatic report converter to throw some
of my reports out as HTML. That works OK but often the report's layout
is distorted and I would like to improve this.

Ideally, I would like to output the reports as PDF, but my client has
locked up the registry for users so I cannot do that (at least not with
Adobe).

Alternatively I could certainly program VBA to output formatted HTML
reports where the content is not distorted. This would work OK but
entails quite a lot of programming effort and I am sure that there must
be an easier method.

I was wondering whether I could build a 'report template' (in HTML) and
then output different data content in XML. Is this possible? And does
anyone know of a good Howto or tutorial that would explain the techniques.

However, I understand that there are some XML techniques which are
specific to Microsoft (e.g. 'data islands' which only work with IE and
not with Netscape or Mozilla). Is this true and, if so, I would like to
avoid these techniques.

Thanks for any help that you can give me.

Regards,
Alan Searle
Nov 13 '05 #1
Share this Question
Share on Google+
27 Replies


P: n/a

First off, you do _not_ need Adobe to create PDF files. There are
plenty of others out there, some of which are free. PDF <> Adobe!

Second, if you do want to pursue the HTML/XML option, I'd strongly
suggest you learn HTML. You may also want to look at just XML (since
HTML is a sub-set of HTML), but that opens such a huge world it may
not be your best course if you have limited time.

The concept of using one HTML "format" for multiple sets of data is
one I can't say as I'd recommend, although I have done these.

Data Islands are a concept that you probably don't want to pursue.
They are more for situations where a HTML form is used to "query" a
collection of data, without a database container being present. Think
of it as Access and Text files. XML is a far more flexible and fast
option, however useless if you _do_ have a database available. There
is however quite a learning process for XML, so as I mentioned before,
if you are limited in time, you probably don't want to pursue that
course, although it is one I'd suggest that is learned.
On Sun, 09 Oct 2005 21:20:11 +0200, Alan Searle
<aj*******@xxxyahoo.com> wrote:
I currently use the MS-Access automatic report converter to throw some
of my reports out as HTML. That works OK but often the report's layout
is distorted and I would like to improve this.
Ideally, I would like to output the reports as PDF, but my client has
locked up the registry for users so I cannot do that (at least not with
Adobe).
Alternatively I could certainly program VBA to output formatted HTML
reports where the content is not distorted. This would work OK but
entails quite a lot of programming effort and I am sure that there must
be an easier method.
I was wondering whether I could build a 'report template' (in HTML) and
then output different data content in XML. Is this possible? And does
anyone know of a good Howto or tutorial that would explain the techniques.
However, I understand that there are some XML techniques which are
specific to Microsoft (e.g. 'data islands' which only work with IE and
not with Netscape or Mozilla). Is this true and, if so, I would like to
avoid these techniques.

--
Drive C: Error. (A)bort (R)etry (S)mack The Darned Thing

Nov 13 '05 #2

P: n/a
Chuck Grimsby <c.*******@worldnet.att.net.invalid> wrote in
news:0c********************************@4ax.com:
You may also want to look at just XML (since
HTML is a sub-set of HTML)


Er, that's not correct at all.

HTML is *not* a subset of XML nor vice versa.

Both are SGMLs (structured generalized markup languages), but XML
tries to be all things to all people by being an eXtensible markup
language.

That aspect of it is more hype than reality, in my opinion, but it's
certainly being widely used.

There's also XHTML, which is a cross-breeding of HTML and XML that I
think is not a good idea (there are issues with content types and
how browsers and web servers treat XHTML that make it fatally
flawed).

HTML by itself is fully sufficient for the purposes of the OP. XML
adds little at all that's of any real use.

Indeed, I believe that client-side XML (i.e., delivered to the web
browser) serves no purpose whatsoever.

But as on so many subjects, I'm something of a curmudgeon about it.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #3

P: n/a
rkc
David W. Fenton wrote:

<snip/>
Indeed, I believe that client-side XML (i.e., delivered to the web
browser) serves no purpose whatsoever.

But as on so many subjects, I'm something of a curmudgeon about it.


No. Come on. Really?
Nov 13 '05 #4

P: n/a
rkc
David W. Fenton wrote:
Indeed, I believe that client-side XML (i.e., delivered to the web
browser) serves no purpose whatsoever.


Interesting because Web Services are the basis of SOA which is
todays saviour of distributed applications. Web Services are
entirely based on sending XML messages in both directions.
Nov 13 '05 #5

P: n/a
On Sun, 09 Oct 2005 21:20:11 +0200, Alan Searle
<aj*******@xxxyahoo.com> wrote:

I currently use the MS-Access automatic report converter to throw some
of my reports out as HTML. That works OK but often the report's layout
is distorted and I would like to improve this.

Ideally, I would like to output the reports as PDF, but my client has
locked up the registry for users so I cannot do that (at least not with
Adobe).
Check out: http://www.docudesk.com. It does a beautiful job of
generating PDF files.

Alternatively I could certainly program VBA to output formatted HTML
reports where the content is not distorted. This would work OK but
entails quite a lot of programming effort and I am sure that there must
be an easier method.

I was wondering whether I could build a 'report template' (in HTML) and
then output different data content in XML. Is this possible? And does
anyone know of a good Howto or tutorial that would explain the techniques.

However, I understand that there are some XML techniques which are
specific to Microsoft (e.g. 'data islands' which only work with IE and
not with Netscape or Mozilla). Is this true and, if so, I would like to
avoid these techniques.

Thanks for any help that you can give me.

Regards,
Alan Searle

Nov 13 '05 #6

P: n/a
It was recently announced by Microsoft that the next version of Office, now
called Office 12, including Microsoft Access, would have native ability to
write PDF. That will be some time, of course, since it is not yet in Beta.

No problem for me, as my very old version of Adobe Acrobat has all the
features I have needed. I've migrated it from machine to new machine over
the years. Haven't loaded it on this machine yet, but I would imagine it
would work OK with Windows XP.

Larry Linson
Microsoft Access MVP
"Alan Searle" <aj*******@xxxyahoo.com> wrote in message
news:di**********@newsreader3.netcologne.de...

I currently use the MS-Access automatic report converter to throw some of
my reports out as HTML. That works OK but often the report's layout is
distorted and I would like to improve this.

Ideally, I would like to output the reports as PDF, but my client has
locked up the registry for users so I cannot do that (at least not with
Adobe).

Alternatively I could certainly program VBA to output formatted HTML
reports where the content is not distorted. This would work OK but
entails quite a lot of programming effort and I am sure that there must be
an easier method.

I was wondering whether I could build a 'report template' (in HTML) and
then output different data content in XML. Is this possible? And does
anyone know of a good Howto or tutorial that would explain the techniques.

However, I understand that there are some XML techniques which are
specific to Microsoft (e.g. 'data islands' which only work with IE and not
with Netscape or Mozilla). Is this true and, if so, I would like to avoid
these techniques.

Thanks for any help that you can give me.

Regards,
Alan Searle

Nov 13 '05 #7

P: n/a

Hi Chuck,
First off, you do _not_ need Adobe to create PDF files. There are
plenty of others out there, some of which are free. PDF <> Adobe!
Yes, I know there are some great tools out there but my client is a bit
quirky having locked up the registry and being very slow to allow new
software to be approved :-/
Second, if you do want to pursue the HTML/XML option, I'd strongly
suggest you learn HTML. You may also want to look at just XML (since
HTML is a sub-set of HTML), but that opens such a huge world it may
not be your best course if you have limited time.
Yes, this was my first thought and I have done it before: I have
written VBA code which 'throws' out HTML reports. This worked very well
but it did take a while to program.

And so I was hoping that XML would give me a quicker and more flexible
path. But going by the feedback that I am getting, XML will only really
help me, if I implement it with a web-database (which is not what I
want: I just want 'dumb' files/reports which can be opened by the user).
The concept of using one HTML "format" for multiple sets of data is
one I can't say as I'd recommend, although I have done these.
OK.
Data Islands are a concept that you probably don't want to pursue.
They are more for situations where a HTML form is used to "query" a
collection of data, without a database container being present. Think
of it as Access and Text files.
Thanks for clarifying this.
XML is a far more flexible and fast
option, however useless if you _do_ have a database available. There
is however quite a learning process for XML, so as I mentioned before,
if you are limited in time, you probably don't want to pursue that
course, although it is one I'd suggest that is learned.
OK.

Thanks very much for your help.

Regards,
Alan Searle
On Sun, 09 Oct 2005 21:20:11 +0200, Alan Searle
<aj*******@xxxyahoo.com> wrote:
I currently use the MS-Access automatic report converter to throw some
of my reports out as HTML. That works OK but often the report's layout
is distorted and I would like to improve this.
Ideally, I would like to output the reports as PDF, but my client has
locked up the registry for users so I cannot do that (at least not with
Adobe).
Alternatively I could certainly program VBA to output formatted HTML
reports where the content is not distorted. This would work OK but
entails quite a lot of programming effort and I am sure that there must
be an easier method.
I was wondering whether I could build a 'report template' (in HTML) and
then output different data content in XML. Is this possible? And does
anyone know of a good Howto or tutorial that would explain the techniques.
However, I understand that there are some XML techniques which are
specific to Microsoft (e.g. 'data islands' which only work with IE and
not with Netscape or Mozilla). Is this true and, if so, I would like to
avoid these techniques.


Nov 13 '05 #8

P: n/a
On Sun, 09 Oct 2005 19:46:12 -0500, "David W. Fenton" <dX********@bway.net.invalid> wrote:
(snip) XML
tries to be all things to all people by being an eXtensible markup
language.

That aspect of it is more hype than reality, in my opinion, but it's
certainly being widely used.
Just like object orientation then.
But as on so many subjects, I'm something of a curmudgeon about it.

No, you're a pussy cat really.
Nov 13 '05 #9

P: n/a
rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
news:Xn*******************@twister.nyroc.rr.com:
David W. Fenton wrote:
Indeed, I believe that client-side XML (i.e., delivered to the
web browser) serves no purpose whatsoever.


Interesting because Web Services are the basis of SOA which is
todays saviour of distributed applications. Web Services are
entirely based on sending XML messages in both directions.


Services are for server-to-server communication, not client-server.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #10

P: n/a
rkc
David W. Fenton wrote:
rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
news:Xn*******************@twister.nyroc.rr.com:

David W. Fenton wrote:

Indeed, I believe that client-side XML (i.e., delivered to the
web browser) serves no purpose whatsoever.


Interesting because Web Services are the basis of SOA which is
todays saviour of distributed applications. Web Services are
entirely based on sending XML messages in both directions.

Services are for server-to-server communication, not client-server.


That's all you have?
Nov 13 '05 #11

P: n/a
First, read the "exporting to xml" topic in Access help. Exporting
reports (from Access 10 and 11) to html or asp works very well, and the
formatting is exactly the same as appears in the Access print preview.
The only thing missing, and I'm working on this, is how to set paper
size and orientation for printing the final report with page breaks and
page numbers. By default, the entire report is displayed in a single
page (with report/page/group headers and footers intact.)

http://msdn.microsoft.com/library/de...tml/vs03g9.asp

http://msdn.microsoft.com/library/de...dc_acxmlom.asp

Hope that helps.

Bob

Nov 13 '05 #12

P: n/a
Not sure whether we are on the same thread of thought, but XML over HTTP
is just a transport mechanism. Whether one wants to formally use it for
server-server, server-client isn't the focus, it's just plumbing. It has
pros and cons like any other plumbing. It doesn't require constant
connection, it is text so can pass through any filters that allow text,
it can default to TCP/IP port 80 so can pass through most firewall setups.

XML over HTTP can be used to simply convey text content or metadata or
it can be used to convey rpc commands - it depends on what you want to
define as the execution engine.

Think about ODBC - that's plumbing that does not specify that you should
do server to server or client to server. You just use it to connect.

Making clients that natively support XML consumption (without extra
ActiveX plugin technology) means that the rest of the non Microsoft
world is now jumping up and down over AJAX and Web 2.0. - Something that
the Microsoft world wanted to establish all those years ago (with
ActiveX client pluging) but the rest of the www would not agree to.

http://accesscoach.wikispaces.org/As...script+And+XML

HTH
Ananda

David W. Fenton wrote:
rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
news:Xn*******************@twister.nyroc.rr.com:

David W. Fenton wrote:

Indeed, I believe that client-side XML (i.e., delivered to the
web browser) serves no purpose whatsoever.


Interesting because Web Services are the basis of SOA which is
todays saviour of distributed applications. Web Services are
entirely based on sending XML messages in both directions.

Services are for server-to-server communication, not client-server.

Nov 13 '05 #13

P: n/a
rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
news:mE*******************@twister.nyroc.rr.com:
David W. Fenton wrote:
rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
news:Xn*******************@twister.nyroc.rr.com:
David W. Fenton wrote:

Indeed, I believe that client-side XML (i.e., delivered to the
web browser) serves no purpose whatsoever.

Interesting because Web Services are the basis of SOA which is
todays saviour of distributed applications. Web Services are
entirely based on sending XML messages in both directions.


Services are for server-to-server communication, not
client-server.


That's all you have?


Eh? You bring up an irrelevancy, and I point out that it's
irrelevant, and you take me to task for not pointing out other
irrelevancies?

If a service has a client-side interface, that interface should
deliver HTML. Period.

XML is not for web browsers -- it serves no purpose whatsoever in
that environment.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #14

P: n/a
Ananda Sim <An*******@gmail.com.invalid> wrote in
news:43**********************@news.optusnet.com.au :
Not sure whether we are on the same thread of thought, but XML
over HTTP is just a transport mechanism. Whether one wants to
formally use it for server-server, server-client isn't the focus,
it's just plumbing.


That's nice, but it doesn't really address the point of contention,
which was my statement that:
Indeed, I believe that client-side XML (i.e., delivered to the
web browser) serves no purpose whatsoever.


A web browser is not a suitable agent for processing XML. That's not
what it's designed for in the first place.

That doesn't mean an XML based service can't deliver HTML to a
client web browser, though. It's only an issue of what the format is
for delivering to the user agentn (i.e., the web browser).

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #15

P: n/a
Hmm? AJAX is all about XML and web browsers.

http://en.wikipedia.org/wiki/XMLHttpRequest

"The biggest advantage of XMLHTTP is the ability to dynamically update a
webpage without reloading the entire webpage or using software plugins
(This was previously only possible using hidden IFRAMEs with DHTML). It
is used by many websites to implement responsive and dynamic web
applications"

The first browsers weren't even GUI - they were text based with
hyperlink things rather like Lynx

Javascript had not been invented, and certainly not XMLHTTPRequest objects.

(Please put on a Chevalier accent and sing the refrain "I remember it
well...")

Ecommerce, web apps would not be possible in this environment.

We're now at 2005, more than 10 years since the GUI Mosaic 1.0

http://www.eskimo.com/~bloo/indexdot.../browsers6.htm

The www certainly isn't what Tim Berners Lee

http://www.w3.org/People/Berners-Lee.../Overview.html

started off with - the "simple" intent to read/write text information
across heterogeneous systems.

I don't think it's just the Access people you have to convince, there's
a whole world of people out there that are gonna use XML in browsers,
whether one like's it or not.

David W. Fenton wrote:
A web browser is not a suitable agent for processing XML. That's not
what it's designed for in the first place.

That doesn't mean an XML based service can't deliver HTML to a
client web browser, though. It's only an issue of what the format is
for delivering to the user agentn (i.e., the web browser).

Nov 13 '05 #16

P: n/a
Hi Bob,
First, read the "exporting to xml" topic in Access help.
OK.
Exporting
reports (from Access 10 and 11) to html or asp works very well, and the
formatting is exactly the same as appears in the Access print preview.
Yes, the default 'output to HTML' is pretty good but we have the
problems you mention ...
The only thing missing, and I'm working on this, is how to set paper
size and orientation for printing the final report with page breaks and
page numbers. By default, the entire report is displayed in a single
page (with report/page/group headers and footers intact.)
.... and find that, as the reports have many columns, often the column
alignment is messed up.
http://msdn.microsoft.com/library/de...tml/vs03g9.asp
http://msdn.microsoft.com/library/de...dc_acxmlom.asp
I'll check out these links.
Hope that helps.


Thanks very much,
Alan.
Nov 13 '05 #17

P: n/a
David W. Fenton wrote:
rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
news:mE*******************@twister.nyroc.rr.com:
David W. Fenton wrote:
rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
news:Xn*******************@twister.nyroc.rr.com:

> David W. Fenton wrote:
>
> > Indeed, I believe that client-side XML (i.e., delivered to the
> > web browser) serves no purpose whatsoever.
>
> Interesting because Web Services are the basis of SOA which is
> todays saviour of distributed applications. Web Services are
> entirely based on sending XML messages in both directions.

Services are for server-to-server communication, not
client-server.


That's all you have?


Eh? You bring up an irrelevancy, and I point out that it's
irrelevant, and you take me to task for not pointing out other
irrelevancies?

If a service has a client-side interface, that interface should
deliver HTML. Period.

XML is not for web browsers -- it serves no purpose whatsoever in
that environment.


In many newer web apps an XML document serves the same purpose as a disconnected
Recordset. You retrieve a dataset in an XML document and you can manipulate
(filter, sort, edit, add, delete) data in the XML document and then commit those
changes to the server in one operation.

Is there another (better) way to persist a Recordset on a web client that you
are aware of?

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
Nov 13 '05 #18

P: n/a
"Rick Brandt" <ri*********@hotmail.com> wrote in
news:rR***************@newssvr11.news.prodigy.com:
David W. Fenton wrote:
rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
news:mE*******************@twister.nyroc.rr.com:
> David W. Fenton wrote:
> > rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
> > news:Xn*******************@twister.nyroc.rr.com:
> >
> > > David W. Fenton wrote:
> > >
> > > > Indeed, I believe that client-side XML (i.e., delivered
> > > > to the web browser) serves no purpose whatsoever.
> > >
> > > Interesting because Web Services are the basis of SOA which
> > > is todays saviour of distributed applications. Web Services
> > > are entirely based on sending XML messages in both
> > > directions.
> >
> > Services are for server-to-server communication, not
> > client-server.
>
> That's all you have?
Eh? You bring up an irrelevancy, and I point out that it's
irrelevant, and you take me to task for not pointing out other
irrelevancies?

If a service has a client-side interface, that interface should
deliver HTML. Period.

XML is not for web browsers -- it serves no purpose whatsoever in
that environment.


In many newer web apps an XML document serves the same purpose as
a disconnected Recordset. You retrieve a dataset in an XML
document and you can manipulate (filter, sort, edit, add, delete)
data in the XML document and then commit those changes to the
server in one operation.


In a web browser?
Is there another (better) way to persist a Recordset on a web
client that you are aware of?


In a web browser?

When I said WEB BROWSER, I meant WEB BROWSER. I can see how I wasn't
clear above in saying "client-side interface," but I was referring
to a browser-based application, as should be clear from my last
line.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #19

P: n/a
Ananda Sim <An*******@gmail.com.invalid> wrote in
news:43***********************@news.optusnet.com.a u:
AJAX


Well, that really doesn't have anything to do with the original
question, which was about getting Access reports onto web pages.

So far as I know, Access reports are not manipulable, so XML/AJAX
provides wouldn't really be relevant to the problem space.

My only point is that there's no need to delve into XML in order to
accomplish the simple task of delivering Access reports to the Web.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #20

P: n/a
On Tue, 11 Oct 2005 19:25:40 GMT, "David W. Fenton" <dX********@bway.net.invalid> wrote:
In many newer web apps an XML document serves the same purpose as
a disconnected Recordset. You retrieve a dataset in an XML
document and you can manipulate (filter, sort, edit, add, delete)
data in the XML document and then commit those changes to the
server in one operation.


In a web browser?


You can plant a recordset into the browser (client) as a javascript array. In fact you can copy a
whole database (within reason!) in this way with one array for each table, indexed on the keys. (Be
warned most browsers implement javascript indexing by linear search). This sort of thing is
useful for browser-based arcade-type games which don't often call the server.
You could also send down an XML file if you prefer the hierarchical to the relational model, as
most people now seem to again.

Nov 13 '05 #21

P: n/a
David W. Fenton wrote:
"Rick Brandt" <ri*********@hotmail.com> wrote in
news:rR***************@newssvr11.news.prodigy.com:
In many newer web apps an XML document serves the same purpose as
a disconnected Recordset. You retrieve a dataset in an XML
document and you can manipulate (filter, sort, edit, add, delete)
data in the XML document and then commit those changes to the
server in one operation.
In a web browser?


Yes, in a web browser.
Is there another (better) way to persist a Recordset on a web
client that you are aware of?
In a web browser?


Yes, IE, Firefox, etc..

When I said WEB BROWSER, I meant WEB BROWSER. I can see how I wasn't
clear above in saying "client-side interface," but I was referring
to a browser-based application, as should be clear from my last
line.


A Client/Server app that runs in a web browser and retrieves data from the
server, persists it in a client side XML document, and then also commits any
changes made to the XML document back to the server.

This is the development environment (Ajax) that my company is using for many
of our new apps.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
Nov 13 '05 #22

P: n/a
rkc
David W. Fenton wrote:
rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
news:mE*******************@twister.nyroc.rr.com:

David W. Fenton wrote:
rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
news:Xn*******************@twister.nyroc.rr.com :
David W. Fenton wrote:
>Indeed, I believe that client-side XML (i.e., delivered to the
>web browser) serves no purpose whatsoever.

Interesting because Web Services are the basis of SOA which is
todays saviour of distributed applications. Web Services are
entirely based on sending XML messages in both directions.

Services are for server-to-server communication, not
client-server.


That's all you have?

Eh? You bring up an irrelevancy, and I point out that it's
irrelevant, and you take me to task for not pointing out other
irrelevancies?

If a service has a client-side interface, that interface should
deliver HTML. Period.


According to DWF. Others might consider XML documents linked to CSS
style sheets useful. Or maybe even XML documents linked to XSLT style
sheets.

Nov 13 '05 #23

P: n/a
Hi David,

Yes we seem to be having a discussion that meanders from the original
post. Looks like people nowadays do want "instant" (just add water)
web reports from Access - see thread:

"how to format xml/xls web report for specific paper size and orientation?"

And the plethora of concepts, terms and jargon is leading people on a
merry chase trying to understand each concept and it's context but there
is not cost-free, effort-free cuppa.

Ananda

David W. Fenton wrote:
Ananda Sim <An*******@gmail.com.invalid> wrote in
news:43***********************@news.optusnet.com.a u:

AJAX

Well, that really doesn't have anything to do with the original
question, which was about getting Access reports onto web pages.

So far as I know, Access reports are not manipulable, so XML/AJAX
provides wouldn't really be relevant to the problem space.

My only point is that there's no need to delve into XML in order to
accomplish the simple task of delivering Access reports to the Web.

Nov 13 '05 #24

P: n/a
polite person <si*****@ease.com> wrote in
news:41********************************@4ax.com:
On Tue, 11 Oct 2005 19:25:40 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:
In many newer web apps an XML document serves the same purpose
as a disconnected Recordset. You retrieve a dataset in an XML
document and you can manipulate (filter, sort, edit, add,
delete) data in the XML document and then commit those changes
to the server in one operation.


In a web browser?


You can plant a recordset into the browser (client) as a
javascript array. In fact you can copy a whole database (within
reason!) in this way with one array for each table, indexed on the
keys. (Be warned most browsers implement javascript indexing by
linear search). This sort of thing is useful for browser-based
arcade-type games which don't often call the server. You could
also send down an XML file if you prefer the hierarchical to the
relational model, as most people now seem to again.


Perhaps you could teach a pig to sing, but I for one would not want
to listen to it.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #25

P: n/a
On Wed, 12 Oct 2005 14:05:43 -0500, "David W. Fenton" <dX********@bway.net.invalid> wrote:
polite person <si*****@ease.com> wrote in
news:41********************************@4ax.com :
On Tue, 11 Oct 2005 19:25:40 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:
In many newer web apps an XML document serves the same purpose
as a disconnected Recordset. You retrieve a dataset in an XML
document and you can manipulate (filter, sort, edit, add,
delete) data in the XML document and then commit those changes
to the server in one operation.

In a web browser?


You can plant a recordset into the browser (client) as a
javascript array. In fact you can copy a whole database (within
reason!) in this way with one array for each table, indexed on the
keys. (Be warned most browsers implement javascript indexing by
linear search). This sort of thing is useful for browser-based
arcade-type games which don't often call the server. You could
also send down an XML file if you prefer the hierarchical to the
relational model, as most people now seem to again.


Perhaps you could teach a pig to sing, but I for one would not want
to listen to it.


Now this is just needlessly rude. Why are you so self-centred? What are you
going to reply to Rick who made the same point?

Nov 13 '05 #26

P: n/a
polite person <si*****@ease.com> wrote in
news:dc********************************@4ax.com:
On Wed, 12 Oct 2005 14:05:43 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:
polite person <si*****@ease.com> wrote in
news:41********************************@4ax.co m:
On Tue, 11 Oct 2005 19:25:40 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

> In many newer web apps an XML document serves the same purpose
> as a disconnected Recordset. You retrieve a dataset in an XML
> document and you can manipulate (filter, sort, edit, add,
> delete) data in the XML document and then commit those changes
> to the server in one operation.

In a web browser?

You can plant a recordset into the browser (client) as a
javascript array. In fact you can copy a whole database (within
reason!) in this way with one array for each table, indexed on
the keys. (Be warned most browsers implement javascript
indexing by linear search). This sort of thing is useful for
browser-based arcade-type games which don't often call the
server. You could also send down an XML file if you prefer the
hierarchical to the relational model, as most people now seem to
again.


Perhaps you could teach a pig to sing, but I for one would not
want to listen to it.


Now this is just needlessly rude. Why are you so self-centred?
What are you going to reply to Rick who made the same point?


I just used a colorful method of saying that just because something
is possible doesn't mean it's desirable.

I saw no point in posting the same response twice.

If you think that was rude, then you really need to get a thicker
skin.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #27

P: n/a
On Wed, 12 Oct 2005 22:02:50 -0500, "David W. Fenton" <dX********@bway.net.invalid> wrote:
I just used a colorful method of saying that just because something
is possible doesn't mean it's desirable.

I saw no point in posting the same response twice.

If you think that was rude, then you really need to get a thicker
skin.

The rudeness is your dismissive manner to anything that you don't like. You could say "Well, I would
never use client side code in a browser for anything myself" (or whatever your view is) or, God
forbid, start a new thread about it rather than just imply that anyone who disagrees with you is an
idiot.

Nov 13 '05 #28

This discussion thread is closed

Replies have been disabled for this discussion.