Replies

Hi Leesha,

I think you’re heading down the wrong path. Microsoft SQL Reporting Services is the tool that you’re working with here – it is what controls the access to the /Reports folder.

Generally speaking, SQL Reporting Services uses Active Directory permissions to allow or deny access to its respective folders and reports. Your best bet would be to search for advice on administering SQL Reporting Services.

Sorry for the late response.

In the case that you’ve described, it seems to make the most sense to run your application as a windows service. Just be sure to make liberal use of logging (i.e. the Windows Event Log or write it out to a text file) so you’ll be able to diagnose any problems or errors. Also, be sure to make things as configurable as possible. For instance, if you do not have control over the website you may want to make an xml template of some sort that can be updated without having to recompile and redeploy the application. Granted, if this is a small one-user situation then it’s probably not a big deal to recompile and redeploy…

Just my .

Try opening the SharePoint document library using WebDav (also called Web Folders). You can drag and drop to copy files just as you would with Windows Explorer.

(Select File | Open in IE, enter the URL of the desired Document Library, check the “Open as Web Folder” option…)

Hi Kevin,
My guess is probably too obvious to be the right answer, but I’ll give it a shot anyway.

It looks like the name of the internal file is passed when creating the first FileStream object (infile, in your example). It looks like the name of the external zip file is created with the second FileStream (outfile). I’m just guessing that the two names do not necessarily need to be identical…

Hope this helps.

Is there any particular reason you need the function to be shared? Try removing the Shared declaration from your function and that should fix the problem.

For more details on the Shared keyword, check here.

The problem is that this is not ASPX code. It’s “Classic” ASP (not .NET).

Did I understand correctly that you have an instance of SQL Reporting Services available? If so, why don’t you use a report to export your data to Excel, PDF, etc.? You can build the report to read its data from the same source that you’re using to present it via the webpage you mentioned.

I don’t mean to send you to resources outside of Woody’s Lounge, but you’ll probably need to start (or continue) looking at other forums that are more development-centric than Woody’s.

Generally speaking, you can’t usually upgrade IIS on Windows 2003. It’s always going to be IIS6 (for now, anyway). There’s no harm in upgrading .NET framework, but it shouldn’t be necessary for what you’ve described. Any version of .NET (1.x or 2.0) should work.

After running the ASP.NET reg iis command that I suggested before, you may also want to check the extensions to insure that the .NET extensions are enabled. I don’t have a 2003 box available to me at the moment, but you’ll want to look around for the extensions property page and verify that ASP.NET is enabled. You should be able to find the how-to in either help files or by a quick google.

It sounds like IIS isn’t aware of the .NET framework. This can sometimes happen depending on the order of installation of IIS and the .NET framework.

You can try making IIS aware of this by running the following command:

C:WindowsMicrosoft.NETFrameworkv1.1.4322aspnet_regiis.exe -i

So is your import code written in Access? If you’re using Access to store and manage the configuration and results, I would recommend that you do the importing there too. You should be able to implement a very similar XML DOM traversing logic using an Access module.

That’s basically the type of approach you’ll want to take. FWIW – I would recommend using the .NET XML objects rather than the external ones, but that’s totally up to you. The method names may differ a little, but the concept is essentially identical.

Now, if you want to take this to the next level, here is a general outline of what you’ll want to do:
– Decide on a structure for storing and presenting the data involved with both the configuration and output of your application. Developers often build custom classes that mirror the data structure (a simple public class with public proerties that match the data type). If you use this approcah, you’ll need to create a second object that’s collection based to store these other items (the signle-item is like a data row and the collection is like a table). You can also use a DataSet – either “virtual” (aka created on the fly) or tied to an XSD that’s created through the designer.
– Take the logic you’re currently using to traverse the XML data and instead, use it to populate the data structure mentioned above. For instance, if you’re using custom classes, iterate each XML Node, instantiate a new class and populate its values, then add it to the collection (rinse and repeat). If you’re using a dataset, iterate the XML nodes, create a new data row and popualte the values, then add to the data table. It’s essentially the same process no matter what sort of objects you choose to use.
– Update the references in your web pages to read from the data object rather than directly from the XML file. This may take a while, but shouldn’t be too bad.

The benefits of this approach are many. This de-couples the front-end from the data source. If you happen to change your data source from XML to SQL Server one day, the only piece that you will need to update is the part that maps the data source to the data object. The front-end could care less where the data comes from as long as it is passed in using the expected object type. This is just one example of the beauty of Object-Oriented development.

Post back if you’d like more detail or direction on any of the above items…

Your design goals make perfect sense – ease of deployment, portability, etc. However, I think the tradeoff is that you’re going to have to do more reading/writing of XML for input and output.

One “automated” XML-reading method you may find helpful is DataSet.ReadXml(). You can load XML content from almost any source (string, textreader, XmlReader, etc) then manipulate it within the dataset. There’s also a corresponding WriteXml() method.

Otherwise, there is really no way around having to manipulate the XML DOM at some level. A typical approach would be to encapsulate all of your XML reading/writing methods into a separate class that allows you to pass some other object (custom class, dataset, etc) back and forth from the front-end pages. This should get you to the place where you can easily present tabulated results to end users.

You may also consider looking into XSLT as a way to transform the XML for display purposes. I’ve used that several times and it’s pretty capable, depending on the XML format and your display needs.

Charlotte,

I was imagining converting the data into CSV as an intermediate means of getting it from a browser into Excel. Short of having a SQL Server instance to leverage, this seems like the quickest (cheapest) and easiest route to go… Just my

Did I understand correctly that you wrote the entire system? If that’s the case, then why did you choose to output XML if you have trouble doing anything interesting with it?

You’ll want to study the classes within the System.XML namespace in the .NET Framework. WIth the objects there, you’ll be able to parse the XML file into an object, iterate through the nodes (and any child nodes) and write this output into some meaningful format.

CSV is VERY easy to write. Simply determine which columns you want to include, create some sort of string variable to hold your values (I’d recommend a StringBuilder), append the value followed by the column. Advance a row, rinse and repeat. When you’ve captured all of the data, dump the output into a text file and set the extension to .CSV.

You’ll find plenty of articles and tutorials with a very minimal amount of searching…

Hi Steve,

I’ve used several techniques in the past for converting data between multiple formats with code and/or tools.

The easiest conversion would be to generate a CSV (comma-separated) format that can be easily opened with Excel. Granted, the user would want to immediately save it into some other format in order to use it for anything meaningful. You can set the HTTP Header (MIME) to the XLS signature so that the user automatically sees the Excel icon when they attempt to download/open the output from this method. Users often appreciate that little touch.

I’m not sure if you have an instance of SQL Server available, but you can easily dump the results into a SQL table, which can be accessed by Excel or Access via ODBC/OLEDB (using the built-in tools in each respective application).

I haven’t looked into the office 2007 formats yet, but I’m sure you can find the schema out there somewhere so that you could convert the XML into an XLSX format, although the total effort involved here might be significantly higher than either of the other two.

Hope this helps!