Alex
When the data has to be updateable you MUST use TempTables. CrossTab
queries are never updateable.
I typically use two temp tables, one to hold the data, and another to
describe it.
In the data table for your data I'd create something like:
CREATE TABLE [tblTemp] (
[TempID] [int] IDENTITY (1, 1) NOT NULL ,
[Dirty] [bit] NOT NULL CONSTRAINT [DF_tblTemp_Dirty] DEFAULT (0),
[CurUserID] [int] NOT NULL ,
[StudentID] [int] NULL ,
[StudentName] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[Temp1] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[Temp2] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[Temp3] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[TempN....] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
)
Where you have as many Temp columns as you think you'll EVER need. If the
database is single user you do not need the CurUserID field.
For the table that describes the data you'll need something like this:
CREATE TABLE [tblDataStruct] (
[ColumnDataID] [int] IDENTITY (1, 1) NOT NULL ,
[CurUserID] [int] NULL ,
[FieldName] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[DisplayName] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
)
Where the Field Name would contain the Name of the Field that holds the data
(Temp1, Temp2, Etc.) and Display Name would be the text that you displayed
in the attached label for the control on your form for the column
(Question1, Question2, etc.).
You may also have to add a few more fields in tblDataStruct to make it
easier for you to mung the edited data back into your normalized data
structure. In my experience the toughest part of this process is
re-normalizing the edited data. You'll be writing code the opens and loops
through a recordset of the temp data, looking for the record from which it
came and updating that record or creating a new record if there was no
original record.
The dirty column will allow this routine to determine if any change was made
on the row and allow you to skip the row when not set. Of course your form
will be responsible to set this field on the afterupdate event. Make sure
that the user can not add new records or delete existing records and you
should be good to go.
It's not really that bad, but there are a lot of steps, and therefore places
for things to go horribly wrong.
Ron W