Why will this not produce current record Number 3

[rtshort]

I have the following code:

If rs.BOF = True and rs.EOF = True Then
With rs
.AddNew
.Fields("UserID&quot.Value = Request.Cookies("UserID&quot
.Fields("CltRefNo&quot.Value = Request.Form("txtRefNo&quot
.Fields("OnrPolicyNo&quot.Value = Request.Form("txtPolicyNo&quot
.Fields("OnrLastName&quot.Value = Request.Form("txtVloLName&quot
.Fields("OnrFirstName&quot.Value = Request.Form("txtVloFName&quot
.Fields("OnrAddress&quot.Value = Request.Form("txtVloAddress&quot
.Fields("OnrCity&quot.Value = Request.Form("txtVloCity&quot
.Fields("OnrStateProv&quot.Value = Request.Form("txtVloStProv&quot
.Fields("OnrPostalCode&quot.Value = Request.Form("txtVloPostalCode&quot
.Fields("OnrCountry&quot.Value = Request.Form("txtVloCountry&quot
.Fields("OnrPhone1&quot.Value = Request.Form("txtVloPhone1&quot
.Fields("OnrPhone2&quot.Value = Request.Form("txtVloPhone2&quot
.Fields("OnrCell&quot.Value = Request.Form("txtVloCell&quot
.Fields("OnrFax&quot.Value = Request.Form("txtVloFax&quot
.Fields("OnrEMail&quot.Value = Request.Form("txtVloEMail&quot
.Update
End With
Response.Cookies("ClaimNo&quot = rs.Fields("ClaimNo&quot.Value

Response.Write (Request.Cookies("ClaimNo&quot)
Response.Write ("Hello&quot
'Response.Redirect "VesselInfo.asp"
Else
rs.MoveFirst
Response.Write ("Already in Database!&quot
End If

Shouldn't this set a cookie for the ClaimNo field in the database? The ClaimNo field is an identity column.

Once the recordset is added I need to know what the ClaimNo is for that record.

I'm using the Response.Write(Request.Cookies("ClaimNo&quot) just to see if the Cookie is working. It's not. Rob
Just my $.02.

 

[hithere]

I'm not positive but...Here goes.

I'm assuming that the connection is already (or still) open. When you do the update, don't you have to have some sort of execute for it to actually write? The way that you have it written here is different from what I'm used to seeing/doing. Can you really do a "with rs" (never seen that)? the syntax I use (maybe try it?) is that you list the column names for your update, then the values so something like:

rs= UPDATE UserID, txtRefNo, etc. VALUES '" & Request.Cookies("UserID&quot &"', '"& Request.Form("txtRefNo&quot &"' etc.
conn.execute rs

I think I missed a set of double quote there but you get the idea.

hth
mb

"Where's the Ka-Boom? There's supposed to be an Earth-shattering Ka-Boom!"
Marvin the Martian

 

[Tarwn]

You can leave your code the way it is written, you just need to do your update before you try to read that field out. I know it appears you are doing your update, but things get a little funny when you use these nifty objects. You actually have to set a couple of flags on your connection, since I am not at my home computer I can't tell you off the top of my head, but I can describe the issue.

Basically you need to set flags to allow immediate updating, the way it is now it will not actually push the update into the database until you close the recordset object. If you check a refernce (w3schools has a few good ones) there should be a list of flags as well as explanations.

Sorry for the lack of a clear answer
-tarwn

 

[rtshort]

Hithere, I use my rs Object like that all of the time. I guess it's in the way you structure your code as to how you can use it. I've never used it like you have. ???

Tarwn, Thanks for the link to the site. I'll work on it a little more keeping in mind that the update occurs later than I thought.

Thanks again. Rob
Just my $.02.

 

[Dynapen]

I believe what you are looking for has to do with the combination of the cursor type, cursorlocation, locktype, and either the rs.refresh, rs.requery, or rs.resync commands.

Basically what was said about the update not happening until you close the record set it correct. But if you set the cursor that you use to open the rs (if you dont define one explicitly it will default, MSDN can tell you which one is the default) to one that will allow you to issue the resync command (again, check MSDN for this) then it will in fact issue the update sooner, and give you back the same recordset.

The only advantage to doing things usinga SQL string, which is the way hiThere suggested, is that you don't have to create the recordset object. Beings it appears that you are getting all your values from a form or cookie, doing it the other way might save you time/space on the server, becuase you have created a recordset in the database, just issued a command for it to execute locally. But you would then have to develope a new way to get your ID number that you need for the cookie. The money's gone, the brain is shot.....but the liquor we still got.

 

[rtshort]

Thanks Dynapen, I'll look that up and see. Rob
Just my $.02.

 

[rtshort]

Dynapen, I used the rs.requery method and it worked like it wanted. I'm new at this and haven't noticed those being options.

Thanks Again. Rob
Just my $.02.

 

[Dynapen]

There are so many options to all of the ASP objects (Recordset, connection, command, etc.....) That it's hard for anyone to get them all. The site on MSDN where it lists them all is probably the best source I have found to see what you can and can't do for each object.

Glad I could help.

Here's the link in case anyone else wants it.

http://msdn.microsoft.com/library/d...us/ado270/htm/dasdkadooverview.asp?frame=true

The money's gone, the brain is shot.....but the liquor we still got.

 

[Tarwn]

Thanks dynapen, better explanation of what I was thinking than I gave Also several other good points in there, so i hope everyone kept a copy for future research.

Concerning the getting a key after using an SQL statement, heh, fun. SOmeone should do that one as a FAQ, I see it every couple weeks or so. For free knowledge, you can get the last key from an automnumber/seeded integer field by executing a second SQL statement right after your first.
For MS SQLServer you would execute a query like:
"SELECT IDENT_CURRENT('tablename')"
which would return the incremented id.
unfortunatly since you haven't locked the table, you may run into false results in the case that you have a heavy hits/second load with requests being satisfied by the db in a catch as can manner. Meaning two people could insert at (relatively) the same time.
Order of execution from db:
INSERTA
INSERTB
GETIDA
GETIDB
In this case person A and person B's pages would both be working under the assumption that the id from INSERTB was ther own, when in fact what happened is that there was no lock on the database to keep it from read/write's however it wanted to.
-Tarwn
-Tarwn