Shipbuilder Posted March 30, 2011 Share Posted March 30, 2011 Is it possible to limit the number of new records that are created on a layout before the complete layout MUST be cleared? I need only a maximum of 14 new records in rows on the layout and I have information listed in the header and footer that stays the same for all 14(maximum) records, however, I don't want the user to be able to create 15 records without having to generate a new document (requisition). Any ideas? Link to comment Share on other sites More sharing options...
efen Posted March 30, 2011 Share Posted March 30, 2011 Are these related records in a portal? If so you can create the related records by script using something like [pseudo code] If Count[related record ID does not equal 14] go to related table and create the new record Else Show custom dialog "Too many records" Exit script End if Link to comment Share on other sites More sharing options...
Shipbuilder Posted March 30, 2011 Author Share Posted March 30, 2011 No, as of now I don't have them in a portal. I have the body of the layout shortened so that each time the use creates a new record, the group of fields will show just beneath the previous group, however, that is my delimma right now, I have no way to keep a user from creating more than 14 records on the layout. They could ultimately create an infinate number of records without having to start a new requisition number. Link to comment Share on other sites More sharing options...
comment Posted March 31, 2011 Share Posted March 31, 2011 The problem is not clear. If they do start a new requisition number - are they then allowed to create more records? If yes, then this has nothing to do with the layout, or the table of the layout. I think you want to use a table of Requisitions, with a portal to a related RequisitionLines table. Then you can make the portal 14 rows high, and possibly use field validation to enforce the rule on the data level as well. BTW, why cannot a requisition have more than 14 items? Link to comment Share on other sites More sharing options...
Shipbuilder Posted March 31, 2011 Author Share Posted March 31, 2011 Hopefully by answering your last question first, that will help. The reason that a requisition cannot have more than 14 records (or lines) is because the actual requisition is a pre-printed, pre-numbered (unique requisition number), three page, carbon copy form that comes to us in books of about 20 requisitions. After 14 lines of entry on one, the user has to start a new requisition, which in turn means they receive a new requisition number. So, the purpose here is to incorporate the existing forms with the database. Maybe that will also answer your first question also. Link to comment Share on other sites More sharing options...
Shipbuilder Posted March 31, 2011 Author Share Posted March 31, 2011 I've attached an example of the requisition. The items in the header and footer will apply to all 14 records listed in the body. You will notice that there is actually room for 16 records on the form, however, I want to reserve the area where the last two records would normally go for comments specific to all of the records in the body.17697 - Point 8 Power - Main Switchboards.pdf Link to comment Share on other sites More sharing options...
Vaughan Posted March 31, 2011 Share Posted March 31, 2011 the actual requisition is a pre-printed, pre-numbered (unique requisition number), three page, carbon copy form that comes to us in books I'd be interested in seeing how these get fed through a printer. These should not be any consideration on the database design. Link to comment Share on other sites More sharing options...
Shipbuilder Posted March 31, 2011 Author Share Posted March 31, 2011 A laser printer with a feed tray takes them in and prints them pretty efficiently. Defeats the purpose of the carbon copy (I should add that the carbon copy isn't the old thin black carbon paper, this is a thicker bond type paper). Link to comment Share on other sites More sharing options...
comment Posted March 31, 2011 Share Posted March 31, 2011 I would let users enter as many items as they need - then do the splitting for them (after they are done). Link to comment Share on other sites More sharing options...
Shipbuilder Posted March 31, 2011 Author Share Posted March 31, 2011 And how would you suggest doing the splitting? Link to comment Share on other sites More sharing options...
comment Posted March 31, 2011 Share Posted March 31, 2011 It depends: if it's only a matter of printing 14 records to a page, then all that's needed is to design the printing layout (based on the Items table!) so. If each group of 14 items needs a unique group number, then you would need another table for the groups and a script to assign a new number to each group of 14 new items. But I am not sure I understand the situation completely - esp. why a computerized database needs to be designed around an old paper form (which will surely go out of style in a short time?). Link to comment Share on other sites More sharing options...
Shipbuilder Posted March 31, 2011 Author Share Posted March 31, 2011 The old paper form IS the complication, however, the reason for its use to date (in regards to my company) is because we have a lot of supervisors in "the field" without access to computers and they hand write these to request materials. Link to comment Share on other sites More sharing options...
Recommended Posts
This topic is 4775 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now