Results Wizzard and asp.net

[Dennis Blondell]

I have created a database connection (asp.net option) using the results
wizard and the page it created is using C# as its default language. It has
also created the global.asa and web.config. Why does it have to do this when
the asp.net code to connect to a database is so simple (according to my
programmer)? I would have liked to learn the basics of asp.net programming
by following what FP does (like I have with HTML) but I now think it would
be easier to knuckle down and learn it myself.

How can I get FP to write in VB instead of C#. Do, or should I, change the
page settings to VB. Should I do that with any site that has and VB in
asp.net?

Can I write to the database using the Results Wizard or other wizard? I was
told that FP only reads data through the wizard.

Why and what is <meta name="ProgId"
content="SharePoint.WebPartPage.Document"> when using the asp.net results
wizard? Surely, I don't need Share Point?

Hope there's net too many questions there

Thanks

 

[Jim Buyens]

-----Original Message-----

I have created a database connection (asp.net option)
using the results wizard and the page it created is
using C# as its default language. It has also created
the global.asa and web.config. Why does it have to do
this when the asp.net code to connect to a database is
so simple (according to my programmer)?

FrontPage stores ASP.NET database connection info in the
web.config file so that multiple pages can use the same
connection information. This is also good practice if you
write your own code.

All ASP.NET applications have a global.asax file.

I don't know for sure why Microsoft used C# to implement
ASP.NET Database Result Regions, but I suspect it's
because they were coming from C++ rather than Visual
Basic 6.

I would have liked to learn the basics of asp.net
programming by following what FP does (like I have with
HTML) but I now think it would be easier to knuckle down
and learn it myself.

Not a good idea. Like most code generators, FrontPage
doesn't create the kind of code a conscientious
programmer would write.

How can I get FP to write in VB instead of C#. Do, or
should I, change the page settings to VB.

I don't believe this is possible. (If it is, someone will
now pop up and tell me.)

Should I do that with any site that has and VB in
asp.net?

I'm not sure what you mean here.

Can I write to the database using the Results Wizard or
other wizard? I was told that FP only reads data through
the wizard.

You can use INSERT, UPDATE, and DELETE commands in a DRW
custom query. But if you're on the verge of learning to
program, I suggest learning to do this in code rather
than learning to trick the DRW.

Why and what is <meta name="ProgId"
content="SharePoint.WebPartPage.Document"> when using
the asp.net results wizard? Surely, I don't need Share
Point?

I would say this tag is extraneous. The people who worked
on creating Web Part Pages may have thrown it in for
all .aspx pages, because in their universe .aspx pages
and Web Part Pages are synonymous. In any event, the tag
is harmless.

Jim Buyens
Microsoft FrontPage MVP
http://www.interlacken.com
Author of:
*------------------------------------------------------*
|\----------------------------------------------------/|
|| Microsoft Office FrontPage 2003 Inside Out ||
|| Microsoft FrontPage Version 2002 Inside Out ||
|| Web Database Development Step by Step .NET Edition ||
|| Troubleshooting Microsoft FrontPage 2002 ||
|| Faster Smarter Beginning Programming ||
|| (All from Microsoft Press) ||
|/----------------------------------------------------\|
*------------------------------------------------------*

 

[Kevin Spencer]

Not a good idea. Like most code generators, FrontPage

doesn't create the kind of code a conscientious
programmer would write.

Actually, Jim, I find the code that FrontPage generates for ASP.Net to be
quite ingenious, unlike its' earlier ASP code. This is probably due to the
fact that ASP.Net is object-oriented, which lends itself well to this sort
of thing. It wouldn't hurt anyone to take a look at how FrontPage does it,
at least for the purpose of "getting their feet wet."

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
http://www.takempis.com
Big Things are made up of
Lots of Little Things.

 

[Dennis Blondell]

Thanks, answers noted, advice taken

FrontPage stores ASP.NET database connection info in the
web.config file so that multiple pages can use the same
connection information. This is also good practice if you
write your own code.

All ASP.NET applications have a global.asax file.

I don't know for sure why Microsoft used C# to implement
ASP.NET Database Result Regions, but I suspect it's
because they were coming from C++ rather than Visual
Basic 6.


Not a good idea. Like most code generators, FrontPage
doesn't create the kind of code a conscientious
programmer would write.


I don't believe this is possible. (If it is, someone will
now pop up and tell me.)


I'm not sure what you mean here.


You can use INSERT, UPDATE, and DELETE commands in a DRW
custom query. But if you're on the verge of learning to
program, I suggest learning to do this in code rather
than learning to trick the DRW.


I would say this tag is extraneous. The people who worked
on creating Web Part Pages may have thrown it in for
all .aspx pages, because in their universe .aspx pages
and Web Part Pages are synonymous. In any event, the tag
is harmless.

Jim Buyens
Microsoft FrontPage MVP
http://www.interlacken.com
Author of:
*------------------------------------------------------*
|\----------------------------------------------------/|
|| Microsoft Office FrontPage 2003 Inside Out ||
|| Microsoft FrontPage Version 2002 Inside Out ||
|| Web Database Development Step by Step .NET Edition ||
|| Troubleshooting Microsoft FrontPage 2002 ||
|| Faster Smarter Beginning Programming ||
|| (All from Microsoft Press) ||
|/----------------------------------------------------\|
*------------------------------------------------------*

 

[Jim Buyens]

Actually, Jim, I find the code that FrontPage generates for ASP.Net to be
quite ingenious, unlike its' earlier ASP code. This is probably due to the
fact that ASP.Net is object-oriented, which lends itself well to this sort
of thing. It wouldn't hurt anyone to take a look at how FrontPage does it,
at least for the purpose of "getting their feet wet."

I agree the ASP.NET CODE is better than the ASP code used to be.
However, I've very skeptical of the approach where FrontPage users try
to let FrontPage write 90% of the code and then the user "patches in"
the rest. Although this sometimes works, it seems to me that the
effort is just as much or greater than writing the page from scratch,
and more prone to failure over time.

I must admit, however, that this is a subjective judgment and
ultimately, there's no accounting for taste.

Jim Buyens
Microsoft FrontPage MVP
http://www.interlacken.com
Author of:
*------------------------------------------------------*
|\----------------------------------------------------/|
|| Microsoft Office FrontPage 2003 Inside Out ||
|| Microsoft FrontPage Version 2002 Inside Out ||
|| Web Database Development Step by Step .NET Edition ||
|| Troubleshooting Microsoft FrontPage 2002 ||
|| Faster Smarter Beginning Programming ||
|| (All from Microsoft Press) ||
|/----------------------------------------------------\|
*------------------------------------------------------*

 

[Dennis Blondell]

Should I do that with any site that has and VB in

I'm not sure what you mean here.

Page Properties
"Design time control scripting"
'Platform:'
'Server:'
'Client:'
also Site Settings
"Default validation script language"
'Client:'

Do I need to change any of these settings to 'VBScript' / Server ASP when
creating a .net site and using VB as the page language? I thought this was
mainly when using VB script in the pages and so FP would write in VB script
itself when needed.

 

[Jim Buyens]

Page Properties
"Design time control scripting"
'Platform:'
'Server:'
'Client:'
also Site Settings
"Default validation script language"
'Client:'

Do I need to change any of these settings to 'VBScript' / Server ASP when
creating a .net site and using VB as the page language? I thought this was
mainly when using VB script in the pages and so FP would write in VB script
itself when needed.

I don't believe any of the settings you mention affect ASP.NET pages.

Look, the following ASP.NET code open an Access database, runs a
SELECT statement, and displays the results in tabular form. You just
put this at the top of your Web page

<%@ Page Language="vb" Debug="true" %>
<%@ Import Namespace="System.Data" %>
<%@ Import Namespace="System.Data.OleDb"%>
<script runat="server">
Public Sub Page_Load(sender as Object, e as EventArgs)
Dim conClsf As OleDbConnection
Dim cmdMbrs As OleDbCommand
Dim rdrMbrs As OleDbDataReader
conClsf = New OleDbConnection( _
"Provider=Microsoft.Jet.OLEDB.4.0;" & _
"Data Source=" & server.mappath("classified.mdb") & ";")
conClsf.Open ' Open database connection
cmdMbrs = New OleDbCommand( _
"select * from members order by memberid", _
conClsf) ' Create command object containing SQL statement.
rdrMbrs = cmdMbrs.ExecuteReader ' Use the command object to create a
' data reader
gridMbrs.DataSource = rdrMbrs ' Hook the datagrid to the
datareader.
gridMbrs.DataBind ' Dump the data from the data reader
' into the datagrid.
rdrMbrs.Close ' Cleanup
cmdMbrs.Dispose ' Cleanup
conClsf.Close ' Cleanup
End Sub
</script>

Then, in the body of the Web page, you add this code where you want
the output to appear.

<aspataGrid id="gridMbrs" runat="server" />

From here on, it's all refining SQL statements and formatting the
datagrid.

This stuff really isn't that tough. There's no reason to spend days
figuring how how FrontPage does it (which is, in essence, the same
way).

Jim Buyens
Microsoft FrontPage MVP
http://www.interlacken.com
Author of:
*------------------------------------------------------*
|\----------------------------------------------------/|
|| Microsoft Office FrontPage 2003 Inside Out ||
|| Microsoft FrontPage Version 2002 Inside Out ||
|| Web Database Development Step by Step .NET Edition ||
|| Troubleshooting Microsoft FrontPage 2002 ||
|| Faster Smarter Beginning Programming ||
|| (All from Microsoft Press) ||
|/----------------------------------------------------\|
*------------------------------------------------------*

 

[Jim Cheshire]

If you are going to use that code, I would not use the native provider. I
would definitly use the managed provider. You will get much better
performance by going straight .NET.

--
Jim Cheshire
Jimco Add-ins
http://www.jimcoaddins.com
===================================
Co-author of Special Edition
Using Microsoft FrontPage 2003
Order it today!
http://sefp2003.frontpagelink.com

Page Properties
"Design time control scripting"
'Platform:'
'Server:'
'Client:'
also Site Settings
"Default validation script language"
'Client:'

Do I need to change any of these settings to 'VBScript' / Server ASP when
creating a .net site and using VB as the page language? I thought this was
mainly when using VB script in the pages and so FP would write in VB script
itself when needed.

I don't believe any of the settings you mention affect ASP.NET pages.

Look, the following ASP.NET code open an Access database, runs a
SELECT statement, and displays the results in tabular form. You just
put this at the top of your Web page

<%@ Page Language="vb" Debug="true" %>
<%@ Import Namespace="System.Data" %>
<%@ Import Namespace="System.Data.OleDb"%>
<script runat="server">
Public Sub Page_Load(sender as Object, e as EventArgs)
Dim conClsf As OleDbConnection
Dim cmdMbrs As OleDbCommand
Dim rdrMbrs As OleDbDataReader
conClsf = New OleDbConnection( _
"Provider=Microsoft.Jet.OLEDB.4.0;" & _
"Data Source=" & server.mappath("classified.mdb") & ";")
conClsf.Open ' Open database connection
cmdMbrs = New OleDbCommand( _
"select * from members order by memberid", _
conClsf) ' Create command object containing SQL statement.
rdrMbrs = cmdMbrs.ExecuteReader ' Use the command object to create a
' data reader
gridMbrs.DataSource = rdrMbrs ' Hook the datagrid to the
datareader.
gridMbrs.DataBind ' Dump the data from the data reader
' into the datagrid.
rdrMbrs.Close ' Cleanup
cmdMbrs.Dispose ' Cleanup
conClsf.Close ' Cleanup
End Sub
</script>

Then, in the body of the Web page, you add this code where you want
the output to appear.

<aspataGrid id="gridMbrs" runat="server" />

From here on, it's all refining SQL statements and formatting the
datagrid.

This stuff really isn't that tough. There's no reason to spend days
figuring how how FrontPage does it (which is, in essence, the same
way).

Jim Buyens
Microsoft FrontPage MVP
http://www.interlacken.com
Author of:
*------------------------------------------------------*
|\----------------------------------------------------/|
|| Microsoft Office FrontPage 2003 Inside Out ||
|| Microsoft FrontPage Version 2002 Inside Out ||
|| Web Database Development Step by Step .NET Edition ||
|| Troubleshooting Microsoft FrontPage 2002 ||
|| Faster Smarter Beginning Programming ||
|| (All from Microsoft Press) ||
|/----------------------------------------------------\|
*------------------------------------------------------*[/QUOTE]

 

[Jim Cheshire]

I take it back. You have to use oledb 4.0 as Jim did with Access. Dang
Access.

--
Jim Cheshire
Jimco Add-ins
http://www.jimcoaddins.com
===================================
Co-author of Special Edition
Using Microsoft FrontPage 2003
Order it today!
http://sefp2003.frontpagelink.com

Page Properties
"Design time control scripting"
'Platform:'
'Server:'
'Client:'
also Site Settings
"Default validation script language"
'Client:'

Do I need to change any of these settings to 'VBScript' / Server ASP when
creating a .net site and using VB as the page language? I thought this was
mainly when using VB script in the pages and so FP would write in VB script
itself when needed.

I don't believe any of the settings you mention affect ASP.NET pages.

Look, the following ASP.NET code open an Access database, runs a
SELECT statement, and displays the results in tabular form. You just
put this at the top of your Web page

<%@ Page Language="vb" Debug="true" %>
<%@ Import Namespace="System.Data" %>
<%@ Import Namespace="System.Data.OleDb"%>
<script runat="server">
Public Sub Page_Load(sender as Object, e as EventArgs)
Dim conClsf As OleDbConnection
Dim cmdMbrs As OleDbCommand
Dim rdrMbrs As OleDbDataReader
conClsf = New OleDbConnection( _
"Provider=Microsoft.Jet.OLEDB.4.0;" & _
"Data Source=" & server.mappath("classified.mdb") & ";")
conClsf.Open ' Open database connection
cmdMbrs = New OleDbCommand( _
"select * from members order by memberid", _
conClsf) ' Create command object containing SQL statement.
rdrMbrs = cmdMbrs.ExecuteReader ' Use the command object to create a
' data reader
gridMbrs.DataSource = rdrMbrs ' Hook the datagrid to the
datareader.
gridMbrs.DataBind ' Dump the data from the data reader
' into the datagrid.
rdrMbrs.Close ' Cleanup
cmdMbrs.Dispose ' Cleanup
conClsf.Close ' Cleanup
End Sub
</script>

Then, in the body of the Web page, you add this code where you want
the output to appear.

<aspataGrid id="gridMbrs" runat="server" />

From here on, it's all refining SQL statements and formatting the
datagrid.

This stuff really isn't that tough. There's no reason to spend days
figuring how how FrontPage does it (which is, in essence, the same
way).

Jim Buyens
Microsoft FrontPage MVP
http://www.interlacken.com
Author of:
*------------------------------------------------------*
|\----------------------------------------------------/|
|| Microsoft Office FrontPage 2003 Inside Out ||
|| Microsoft FrontPage Version 2002 Inside Out ||
|| Web Database Development Step by Step .NET Edition ||
|| Troubleshooting Microsoft FrontPage 2002 ||
|| Faster Smarter Beginning Programming ||
|| (All from Microsoft Press) ||
|/----------------------------------------------------\|
*------------------------------------------------------*[/QUOTE]

 

[Jim Cheshire]

Here we go. I knew I had used a managed provider for accessing Access!

http://www.microsoft.com/downloads/...28-7071-4979-8a67-3cffcb0c2524&displaylang=en

It's not included in the .NET Framework version 1.0, but it is available via
download. By using the managed provider, you will get much better
performance.

--
Jim Cheshire
Jimco Add-ins
http://www.jimcoaddins.com
===================================
Co-author of Special Edition
Using Microsoft FrontPage 2003
Order it today!
http://sefp2003.frontpagelink.com

 

[Dennis Blondell]

Sorry, Jim, didn't quite follow but are you saying that the .NET server
controls eg. oledb 4.0 override what ever page and server settings you have
in FP? and that managed providers can work better than native ones? Wait a
minute, don't worry about the second question, I am only up to chapter 3 of
"ASP.NET Developer's JumpStart" and easily confused (he says while sucking
his thumb

 

[Jim Cheshire]

oledb 4.0 is not a server control. It's a technology for access data
sources, and oledb 4.0 is native meaning that it is not designed to run
under the Common Language Runtime and the .NET Framework. The .NET
Framework allows you to reference it, but in order for it to run, .NET has
to add an additional layer to marshal the data between native and managed.

The post you replied to is actually in correct. I stated that you have to
use oledb 4.0 to access an Access database, but in fact I was wrong. You
can download a managed provider, a provider that was written specifically to
work with the .NET Framework, that will allow you to use an Access database.
A managed provider is always the best choice.

--
Jim Cheshire
Jimco Add-ins
http://www.jimcoaddins.com
===================================
Co-author of Special Edition
Using Microsoft FrontPage 2003
Order it today!
http://sefp2003.frontpagelink.com

 

[chris leeds]

I don't know much but this:
http://www.connectionstrings.com/
has helped me when floundering.
I'm sure you don't need it jim but others might. ;-)
HTH

 

[Jim Buyens]

Sorry, Jim, didn't quite follow but are you saying that the .NET server
controls EGA. oledb 4.0 override what ever page and server settings you have
in FP? and that managed providers can work better than native ones? Wait a
minute, don't worry about the second question, I am only up to chapter 3 of
"ASP.NET Developer's JumpStart" and easily confused (he says while sucking
his thumb

Native providers (such as System.Data.SqlClient) are more efficient
than the generic provider System.Data.OleDb, because native providers
use fewer layers of software and translation. Native providers take a
straighter path, if you will.

Jim Cheshire thought to make about a point about the sample code I
posted, because it uses the generic System.Data.OleDb provider. But
there *is* no .NET native provider for Access, and he corrected
himself.

None of which has anything to do with page and server settings in FP.

Jim Buyens
Microsoft FrontPage MVP
http://www.interlacken.com
Author of:
*------------------------------------------------------*
|\----------------------------------------------------/|
|| Microsoft Office FrontPage 2003 Inside Out ||
|| Microsoft FrontPage Version 2002 Inside Out ||
|| Web Database Development Step by Step .NET Edition ||
|| Troubleshooting Microsoft FrontPage 2002 ||
|| Faster Smarter Beginning Programming ||
|| (All from Microsoft Press) ||
|/----------------------------------------------------\|
*------------------------------------------------------*

 

[Jim Cheshire]

System.Data.OleDb is not a provider, nor is it native.
System.Data.SqlClient and System.Data.OleDb are both managed namespaces.
Within them are managed classes that allow you to access data sources.
Neither is native. SqlClient is simply optimized for accessing SQL Server
databases.

Your code, Jim, used the native provider Microsoft.Jet.OLEDB.4.0. (When
using the managed provider, you don't specify a Provider in the connection
string.) I did originally correct myself, but it turned out that I was not
imagining things. You can (and should) use a managed provider with Access
as well, and I posted a link where you can download the managed provider
from Microsoft for use with Access and other non-SQL Server data sources.

--
Jim Cheshire
Jimco Add-ins
http://www.jimcoaddins.com
===================================
Co-author of Special Edition
Using Microsoft FrontPage 2003
Order it today!
http://sefp2003.frontpagelink.com

 

[Dennis Blondell]

I must be learning something here as I am actually beginning to understand
what you guys are talking about We are using System.Data.OleDb and
OLEDB.4.0. We have found this to work fine. He said he found it hard to get
info from the net on connecting to mdb's in .NET as most of the help is
available for SQL instead. We will change the site over to MS SQL in the
future but we designed on the fly and didn't have the time to learn to use
SQL Server (I have queries and reports coming from the mdb) and only now
have a host that provides it free. He realises that a managed namespace is
designed for .NET and OLEDB.4.0 is not, but doesn't know if there will be
more than a few ms difference either way. I will send him your link but
could you please give us more details about the advantages in using a
managed namespace? I think he is concerned about connections to the mdb
being left open after data is grabbed. He can shut the connection easily
using the Jet OLEDB.4.0. He passed that info to me over the phone today,
hope it is not too vague.

But still, getting back to FP and the Site and Page settings, Do I not need
to set them to anything (VB Script / ASP Server) when using ASP.NET? Do the
namespaces override this?

You guys are very helpful

 

[Dennis Blondell]

Interesting little site there Chris, have to remember it when I get to the
stage I can do more in .NET that what I can now. Still trying to understand
simple concepts 'Namespace', thats where ya write ya name on a job
application isn't it? (^o^)

 

[Jim Cheshire]

Dennis,

Closing the connection is the same regardless of which provider you are
using.

Here's an article from MSDN on using managed providers and the benefits you
get by doing so:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndive/html/data010112001.asp

If you use the 1.1 Framework, you'll get access to the System.Data.Odbc
namespace. This namespace provides managed access to JET databases so that
you don't have to use OLEDB 4.0. There is also a download for it for the
1.0 Framework, but if I'm not mistaken, it was in beta and is really only
supported in the 1.1 Framework.

--
Jim Cheshire
Jimco Add-ins
http://www.jimcoaddins.com
===================================
Co-author of Special Edition
Using Microsoft FrontPage 2003
Order it today!
http://sefp2003.frontpagelink.com

 

[Dennis Blondell]

Thanks Jim, both of us have 1.1 so download not needed.