Insättning av nya poster kräver några modifieringar i tabellhanteringen från tidigare
exempel.
Den största skillnaden är att vi hitintills öppnat tabellen som ReadOnly vilket inte
tillåter insättningar eller ändringar. Man bör dock beakta att det är snabbare att lista
en ReadOnly, ForwardOnly tabell än en som tillåter förändringar. Man bör därför alltid öppna
tabeller så enkelt som möjligt.
För insättingar duger dock inte ReadOnly. Följande "öppningsprocedur" skall användas:
<div class=code>
 

<% 
' SQL satsen för tabellen 
SQL = "SELECT * FROM TABELLNAMN" 
Set Conn = Server.CreateObject("ADODB.Connection") 
Conn.Open strConn 
Set RS = Server.CreateObject("ADODB.RecordSet") 
' Måste öppna ett recordset för uppdatering - 2 eller 3 som sista 
' parameter 
RS.Open SQL, Conn, 1, 3 
</div>
I raden RS.Open SQL, Conn, 1, 3
betyder 1:an att vi öppnar tabellen som KeySet (jag tänker inte gå in på vad detta exakt betyder, bara
konstatera att det brukar vara den bästa i denna situation).
3:an betyder att vi vill använda s.k. Optimistic Locking vilket betyder att
ADO låser posten så sent som möjligt före Update. 
Ett annat alternativ skulle kunna vara 2 som ger oss Pessimistic Locking. Detta betyder att posten låses
så fort vi börjar göra någonting.
I detta sammanhang då vi vill skapa en post, sätta dit värden och spara duger Optimistic (3) bra...
Vi kan efter att ha öppnat tabellen med ovanstående metod göra följande 
<div class=code>

<% 
RS.AddNew 
RS("FÄLT1") = Värde1 
RS("FÄLT2") = Värde2 
RS("FÄLT3") = Värde3 
RS.Update 
 
RS.Close 
Conn.Close 
Set RS = Nothing 
Set Conn = Nothing 
%> 

</div>
Fullt så enkelt är det dock inte alltid.
Vad händer till exempel vid följande kod om fältet är numeriskt?
<div class=code>

<% 
RS.AddNew 
RS("NUMMERFÄLT") = "TEST" 
RS.Update 
%> 

</div>
Eller vid följande om fältet inte har "Allow Zero Length" satt?
<div class=code>

<% 
RS.AddNew 
RS("TEXTFÄLT") = "" 
RS.Update 
%> 

</div>
För att inte tala om det största problemet:
<div class=code>

<% 
RS.AddNew 
RS("DATUMFÄLT") = "12.1.1999" 
RS.Update 
%> 

</div>
Om vi tar det sista problemet först så kan vi konstatera att den 12 januari år 1999 kan skrivas som<ul>
<li>12.1.1999
<li>1.12.1999
<li>1999.1.12
<li>1999.12.1
<li>12.1999.1
<li>1.1999.12
<li>Och dessutom kan det vara . eller / eller något annat tecken mellan de olika delarna
<li>Och sedan kan vi ju börja fundera på om år skall ha två eller fyra sifror.
</ul>
I en ideal värld har vi följande:<ul>
<li>Användaren av programmet är finsk
<li>Sidan har LCID=2077 eller 1035 för att säga att den är finlandssvensk eller finsk
<li>Databassystemet är inställt för finsk standard
<li>Serverdatorn har finska inställningar
</ul>

Om samtliga dessa villkor är uppfyllda så är det inga problem, men...
Det är inte alltid t.ex. servern har korrekta inställningar och då får vi PROBLEM!
Det verkar dock som om det alltid går att använda datering enligt amerikanskt
system oavsett hur datorn är inställd. Detta betyder att vi alltid skall ange datum
i formen mm/dd/yyyy alltså månad dag och år

Det svåra är att avgöra vad som kan betraktas som fel. Man skulle kunna tänka sig
att sätta in en nolla (0) om en siffra inte är giltig, eller Null.
I ovanstående funktion så returneras false, man är det rätt i alla situationer?

Detta är en betydligt större fråga än vad ni kanske tänkt på...
Är ni bra på SQL kan även följande instättningsmetod användas 
<div class=code>

' ... 
strSQL ="INSERT INTO TABELL " 
strSQL = strSQL & " (FÄLT1, FÄLT2,NÄR)" 
strSQL = strSQL & " VALUES (" 
strSQL = strSQL & värde1 & ", " 
strSQL = strSQL & värde2 & ", " 
strSQL = strSQL & "NOW" & ")" 
Conn.Execute strSQL 
' ... 

</div>
Det är denna metod jag själv använder mest. Jag har dock märkt att mina
elever ofta slarvar bort sig när de skall börja skarva ihop långa teckensträngar...