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]
