Responses in bold below:

>Hi Mike:
>
>You are right, I also had a problem with authentication too! I even got my host provider to assist me with the wwsession object but we never got it to work. I ended up using my own methods which I think gave me something more suitable because I have to maintain over 100 variables on each user.

Yes - I always roll my own authentication schemes, and call it from sensitive pages to make sure they're 'logged in' with proper rights. Heck, that's a lot better than depending upon Windows accounts for every user!

>I haven't stuck my nose very far into XML but I have the impression that it is more flexible for handling various types of media.
>
>The files that I would be transferring to and from my Web Site would be .dbf files. Would there be an advantage for using XML for that type of transfer?

Depends... XML is a record by record process. If you can integrate a time/date stamp or a 'modified' field into your tables so that you can send only the records that have changed - and if you can isolate the number of files to be received in a similar manner, then I'd go with XML. Rick has done some testing on relative speeds, and has found that fixed-field length in tables vs trimmed fields in XML makes speed comparison difficult without testing your particular situation (table structure and data).

>One thing I have been reading is to be wary of too much graphics in a Web Site because of delays in rendering and inconsistencies in viewing. Possibly XML will address this issue.

No... good page design solves that issue. You can do some slick stuff with XML and CSS, but it takes discipline. If a web designer doesn't have the discipline to carefully design web pages with download times and browser types in mind, I suspect they won't be very good at using the strict XML/CSS structures (which, by the way, have no effect on graphic file sized/download times - just on the organization and presentation of data).

>
>Mike Smith

Good luck...