What you should do is loop thru the multiple entries, and do a db
insert for each entry.
If you continue in the current direction (non-atomic) you will create a
nightmare --
Just consider what you (and the db engine) will need to do to find
records in the db:
-- All cassettes with an issue date between Jan o3 and Jun 03
-- display all cassettes in alphabetic order by title
If you are going to save a structure, you might as well save it in a
text file -- an rdbms won't offer much advantage.
Dick
On Sep 10, 2004, at 5:54 AM, Tim Laureska wrote:
> Dick,��when I first posed the question of how to insert multiple data
> entries at one time, the subject of structures and arrays came up and
> that's why I'm in this direction... is this the wrong direction for
> this
> effort?
>
> -----Original Message-----
> From: Dick Applebaum [mailto:[EMAIL PROTECTED]
> Sent: Friday, September 10, 2004 8:32 AM
> To: CF-Talk
> Subject: Re: inserting structure data into a database
>
> Tim
>
> One of the basic rules of good relational db design is that each
> entity
> (record, row, column) should be atomic -- represent only one thing,
>
> You should not insert a structure into a db
>
> Rather, insert each cassette as a separate row (record) in the db
>
> If there is a relationship among the multiple cassettes that you
> currently have in the structure, consider adding an identifier (group)
> to each record in the db.
>
> ���ID
> ���Title
> ���IssueNumber
> ���IssueDate
> ���Group
>
> Dick
>
> On Sep 10, 2004, at 5:23 AM, Tim Laureska wrote:
>
> > Just learning structures, but here goes:
> >
> >��When I insert structure data into a database, it's inserted into
> each
> >��field as a comma delimited list.��
> >
> >��In this scenario, I'm inserting audio cassette tape information
> into
> > the
> >��database from a form when multiple cassettes are entered at one
> time.
> >��There are three attributes to for each cassette... title, issue
> date
> > and
> >��issue number, which are the fields in the database (along with an
> > autoid
> >��field).
> >
> >��So if three cassettes are entered and subsequently inserted into
> the
> >��database, the data goes in as such:
> >
> >��Auto id��� title field��� ��� issue number field�����issue date
> >��field
> >
> >�����1������ title1, title2, title3��issue1,issue2,issue3
> >��date1,date2,date3
> >
> >��This seems to present a problem in that each cassette does not
> have a
> >��unique autoid to identify it individually and that may present
> issues
> >��further in the application...
> >
> >��My questions are:��1) is this analysis correct and 2)how can you
> >��maintain a unique id for each cassette in this situation ... do you
> > have
> >��to assign a unique number for each cassette using some sort of CF
> code
> >��or is there a way to still utilize the DB's automatic unique id
> >��assignment feature?��
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
