forms and database

max · 06-16-2002, 10:35 PM

1.
<%@ Language=VBScript %>
<% Option Explicit %>


<HTML>
<BODY>
<FORM ACTION="ProcessOrder.asp" METHOD=POST>
<SELECT NAME="ShippingChoice">
<%
Dim objRS
Set objRS = Server.CreateObject ("ADODB.Recordset")
objRS.Open "tblShipping", objConn, , , adCmdTable
Do While Not objRS.EOF
Response.Write "<OPTION VALUE='" & objRS("ShippingCode") &"'>"
Response.Write objRS("Description")
objRS.MoveNext
Loop
objRS.Close
Set objRS = Nothing
objConn.Close
Set objConn = Nothing
%>
</SELECT>
<INPUT TYPE=SUBMIT VALUE="Submit">
</FORM>
</BODY>
</HTML>
2.<%
Dim objConn
Set objConn = Server.CreateObject("ADODB.Connection")
objConn.ConnectionString ="Driver={Microsoft Access Driver (*.mdb)};"& "DBQ=C:\My Documents\WidgetWorld.mdb"
objConn.Open
%>
3.

<%
if NOT Request.form("EmployeeName") = "" then %>


<%End if%>

The user select an option from the drop down menu, and he will get the reult from the database. THat is my goal. So, what is wrong with the code?

JohnKrutsch · 06-17-2002, 01:09 AM

So what works so far and what doesn't? I do not see where you querry the DB for the recordset you need to fill the HTML select box?

It sounds like you want to get the info for the select box from the DB, have the user make a selection from those options then send the selected options to your ProcessOrder.asp page.

So what part of this works already, what part is broken, and what specifically are you trying to do? If you can expalin more of what the problem and end goal is we can be of more help.

glenngv · 06-18-2002, 02:08 AM

that is a DSN-less connection for an Access database. As long as the database is on the correct path on the server, it will work just fine. Of course if it's going to be published somewhere else, the db should be on the server directory and the path in the db connection should be changed accordingly.

Quote:

Originally posted by Dave Clark

Also, the one exposed connection seems to be using a local database file. Is that what you're doing? I ask, because that line is not the best way to code a dynamic database connection (in other words, one that will work both on your local PC and on a site that you may or may not intend to publish this page to).

OK?

whammy · 06-18-2002, 02:18 AM

exposed = DSN-less

ReyN · 06-18-2002, 04:54 AM

Hi

Here's a working example of what John was referring to, if this was what you meant: a select box that is populated from a db, the selected value of which is used as a variable in a query to fetch the result set.

Dynamic Queries

QuackHead · 06-18-2002, 02:31 PM

Quote:

Originally posted by Dave Clark

Code:

<%@ Language=VBScript %> <% Option Explicit %>   <% If Request.ServerVariables("REQUEST_METHOD") = "POST" Then %>   <% End if %>

I'm not sure, but when you use the Include file command you can't really use it in an if statement. As soon as IIS (Or whatever server you're using) processes the ASP, it'll include the files regardless of your "IF" condition.

I've tried using a dynamic include (IE - Include this file if it's this condition, or include this file if it's another condition.)

It didn't work for me. - I read somewhere that it's very unpredictable whether or not this will work.

Just thought I'd give you the heads up, in case you run into problems.

~Quack

whammy · 06-18-2002, 11:52 PM

P.S. Here's a DSN-less Access DB connection that works on brinkster, at any rate:

Set Conn = Server.CreateObject("ADODB.Connection")
sConnString = "Provider=Microsoft.Jet.OLEDB.4.0; Data Source="
sMapPath = Server.MapPath("\")
sMapPath = Mid(sMapPath, 1, InStrRev(sMapPath,"\")-1) & "\database\databasename.mdb;" & _
"Persist Security Info=False;"
sConnString = sConnString & sMapPath
Conn.Open sConnString

Set Conn = Nothing

justame · 06-19-2002, 03:07 AM

Quote:

ReyN posted...

/me just a whispers®...

just a heyyytheres® rey...:O))) great to see ya made it just a over® to the codingforums :O)))

ReyN · 06-20-2002, 01:21 PM

Hi, just a little something on this Server.MapPath thingy:

Server.MapPath returns the physical file path that corresponds to the specified virtual path on the Web server.

This is useful (in fact is obligatory) in cases where the data source is not in the same directory as the calling page. Dave's logic might have been better seen as follows:

The physical path to the data source in your local drive may not be the same physical path on the Web server, even if your local web has the same exact file structure as your web on the remote machine, as the mapping or assignment of the virtual root of your web app in your local host may not be the same as on the remote server.

For instance, the files for my site are physically located at c:\aspxtreme in my local machine.

In aspalliance.com (the mother site of aspxtreme), all columnists' virtual directories are physically located on d:\domains\aspalliance.com\ plus the name of the columnist's virtualdir . . . (in my case, aspxtreme)

Using Server.MapPath with the specified virtual path, for example:

/aspxtreme/shared/data/whatever.mdb

ensures that the data source would be referenced correctly whether I am working locally or on the remote.

No offense, whammy but that code at brinkster is totally unnecessary. A simple Server.MapPath that points to your data source as seen from your virtual root will do. For example, this alone will work:

strConn = "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=" &
Server.MapPath("/virtualroot/subdir/whatever.mdb")

Hello justame.

ReyN · 06-20-2002, 01:21 PM

btw

Server.MapPath is not necessary for SQL Server data. SQL data could be anywhere, in another drive or even in another remote machine, and the path is automatically mapped when you attach the database to the instance of SQL Server you will be using.

whammy · 06-20-2002, 07:16 PM

I would have thought it was unnecessary, as well - yet when I used a simple connection string (actually I believe it was identical to the one you posted), I always got errors on brinkster. I usually use a very simple one at work (when I actually use an Access DB, that is - which is very rarely).

I'd have to try it again to be sure, though.