"Recordsets" in Java Applets

The shop I work in is a Microsoft shop using SQL Server 7.0 and ASP [pause for boos], but I've been a weekend Java programmer for about two years now.
My question for all the kind Java Ranchers here is if anybody knows if it is possible to pass an ADO Recordset to a Java Applet, or should I stick with my gut instinct and call a stored procedure from within the applet based on parameters in the HTML applet tag?
This issue we are facing isn't an earth-shattering issue, but we are looking for a way to basically 'freeze' the column headers of a table (from a custom report, i.e. query off the database) while the user scrolls through the results. Frames aren't really an option and we want to be able to support both IE and NN, so ActiveX controls [pause for more boos] are also out of the question. A coworker of mine suggested a Java Applet and I ran with the idea.
Comments, suggestions, ridicule?

An ADO Recordset isn't a Java Object. In fact, it's not even a particularly portable object at all -- you'd have to write a platform-specific glue module to use it. In Java, you'd use JNI.
Microsoft's architecture encourages fat clients and sloppy code design to provide short-term productivity. You'll find that in Java a much cleaner approach is to design for the enterprise with a 3-tier approach. In this case you may sometimes not even need an applet at all, since all the logic is on the server. Or your applet will handle advanced display and editing, but the data access is done through an HTTP tunnel to the server.
Putting active logic on the client side is discouraged for a number of reasons.
1) ANY code on a client machine can be hacked or spoofed for nefarious purposes
2) JDBC (Java's native database interface) cannot be used in an applet without an involved applet signing process.
3) Even if you did get all the proper authorizations, you might find that port 1433 (the SQL Server TCP/IP port) is blocked by firewalls (and it very frequently is).
4) Although it makes for a more complex product, the ongoing support (both for code and in terms of operating the system) is usually easier if the data (and frequently-changed business logic) is kept on a server. Client machines are often not kept backed up as scrupoulously for one thing.
5) Oh, yes. One other thing. ADO won't work if you have users running Linux or the Mac OS - at least without a lot of expensive support. And I do most of my web access from a Linux machine - my Win/98 machine is too unstable and I can't migrate to NT/2000 because some of my favorite Windows apps and toys won't run there.