Hi y'all, I've got just one final problem: my CRUD offers functionality only for the field I listed in my scaffolding. Despite the fact that I created and successfully executed an addition fixture, none of those fields is included in the CRUD.
The only way I can think of to generate CRUD for all my fields is to redo my scaffolding with all the fields listed in that command. That'll generate the fixture equivalent to my second fixture, for which I'll have no immediate need. IMHO, listing all those fields on a scaffold command is an ugly approach, when compared to the second fixture that listed all the fields. Is there an easier way? Thanks in advance, Richard On Oct 23, 7:58 am, RichardOnRails <[EMAIL PROTECTED]> wrote: > Hi All, > > Sorry. Mea culpa. Another stupid error: I had the "name:type" syntax > backwards. After I straightened that out everywhere, I: > 1. ran the first migration alone -- ran OK > 2. created the second migration > 3. ran the second migration -- ran OK > > BTW, I added ", :force => true" in the second migration because I > thought it necessary since I was replacing the first table definition > with an expanded definition. Was that really necessary? > > I haven't confirmed the database is constructed correctly (using SQL), > but I'll get to that now. > > I hope none of you labored over my long script. > > Best wishes, > Richard > > On Oct 23, 12:02 am, RichardOnRails > > <[EMAIL PROTECTED]> wrote: > > Hi All, > > > I running Ruby/Rails versions: > > ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-mswin32] > > Rails 2.0.2 > > > I ran: > > ruby script/generate scaffold Payroll string:Client_Code > > and got 001_create_payrolls.rb: > > class CreatePayrolls < ActiveRecord::Migration > > def self.up > > create_table :payrolls do |t| > > t.Client_Code :string > > > t.timestamps > > end > > end > > > def self.down > > drop_table :payrolls > > end > > end > > > I didn’t want to add all the variables I wanted to the scaffold > > invocation. So I created a second migration 002_create_payrolls.rb: > > class CreatePayrolls < ActiveRecord::Migration > > def self.up > > create_table :payrolls do |t| > > t.Client_Code :string > > t.Date :date > > [snip] > > t.EE_Num :integer > > > t.timestamps > > end > > end > > > def self.down > > drop_table :payrolls > > end > > end > > > Here’s the problem. I ran: > > rake db:migrate > > and got: > > -- create_table(:payrolls) > > rake aborted! > > undefined method `Client_Code' for > > #<ActiveRecord::ConnectionAdapters::TableDefinition:0x3154278> > > > I thought the problem might be that 001 created the payrolls database, > > and 002 did the same thing ... an obvious conflict. So I modified 002 > > to precede the create_table statement with: > > drop_table(:payrolls) > > That gave me: > > == 2 CreatePayrolls: migrating ======================================= > > -- drop_table(:payrolls) > > rake aborted! > > SQLite3::SQLException: no such table: payrolls: DROP TABLE payrolls > > > I tried running with the –trace option but it failed immediately the > > same way. > > > I realize I could just replace 001's content with 002's and discarding > > 002. Or I could switch 002 to add_column statements. But I'd like > > to learn how these multiple migrations work. > > > Any observations would be most appreciated. > > > TIA, > > Richard --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
