INSERT INTO statement (data not showing correctly)

[tincan56]

Hi. I am really stuck with an issue. I am trying to insert date from an orginal table to another table within the same database. However, with the INSERT INTO SQL statements that I have is not giving the correct data from the orginal table. Both orignal table and the new table have text field. I would really appreciate for any suggestions and help!

**************Here is the VBA/SQL code.
Dim db As Database
Dim rec As Recordset
Dim strSQL As String
Dim dtBillingStart, dtBillingEnd As Date
Dim i As Integer
Dim dtTemp As Date
Dim dtBillingMonth
Dim intBlanketNum As String

Set db = CurrentDb()
Set rec = db.OpenRecordset("GRS Detail&quot

rec.MoveFirst
While Not (rec.EOF)

intBlanketNum = rec("Blanket Number&quot


For i = 0 To DateDiff("m", dtBillingStart, dtBillingEnd)
DoCmd.SetWarnings False
dtTemp = DateAdd("m", i, dtBillingStart)

strSQL = " INSERT INTO TempTable([Blanket Number]) Values(" & intBlanketNum & &quot "
MsgBox (intBlanketNum)

DoCmd.RunSQL (strSQL)

Next i
rec.MoveNext
Wend

rec.Close
End Sub

*********This is what I am getting in the results in the new table - and I am not too sure where these numbers came from.
934
933
682
688

*********This is the data from the original table.
1003-302
1003-312
1003-326
1003-341

 

[daveg232]

this probably isnt it but the
Dim dtBillingMonth isnt set

 

[larryww]

I only had time for a quick read and thus quick response, but use it FWIW. Right after assigning strSQ, add these 2 lines temporarily, and exercise that F5 typing finger

debug.print &quot;<&quot; & strSQ & &quot;>&quot;
stop
(I use the brackets so I can see embedded blanks.)

At least assure yourself as to what it's doing.

A next step might then be to replace INSERT INTO with SELCET.

This is all elementary advice so forgive me if it's beneath you.

P.S. it's difficult to follow the code as it appears in the message; perhaps a hard <TAB> symbol got morphed when you pasted it. So I don't know if you use standard indenting, but if not, that can be more than valuable with code

 

[larryww]

Of course, I just meant strSQL instead of strSQ, and SELECT rather than SELCET. Accuracy, smaccuracy