I want to develop a form for stitching unit where a dress made with 3 or 4 or 5 pieces(trouser, shirt, sleeves, lace, scarf etc)
I want that if I enter in master block that dress is 4 pieces then only 4 record should enter in detail block
You can create a master-detail form.
Then on the master-block you create a post-insert trigger.
In this trigger you can do the insert in the tabel of the detailed block for the number of records you need.
In the key-commit trigger, you do a commit and a requery of the detailed block.
commit_form;
go_block('detail_block');
do_key('execute_query');
Related
Lets say I'm building foursquare, users can edit venues and the changes will not take place immediately till an admin approve them,
I have a Table for Venues,
So for the functionality I explained above do I need another table Called may be 'ProposeEdits' to save the edits for a Venue and then when accepted mark them done ?
Absolutely No.
You Need To add just one column to the end of your table Venue called status.
And Make one Page in PHP for admin called AcceptVenue.php.
When user edits the Venue you just set status to No
And when admin opens AcceptVenue.php list all edits in tabular form with two buttons accept or reject.
When admin accepts and edit just update the status to YES else keep it unchanged.
I am not posting the code.First You try then I will help you if you face any problem.
Scenario:
Venue table : (id,name,venue,date,event,status-default=NO)
user edits the values but the Status Remains Unchanged
Admin opens the AcceptVenue.php
List all records like this:
Name Venu Date Event Action
xyz zux 12/12/12 xyz Accept Reject
Based on admin action run sql query
"update venue set status='YES' where id='venueId'"
Update 2
If you want to keep both versions:
proposedEditTable
(id,name,venue,date,event,original_venue_id,status-default=NO)
When admin accepts the Edit You just need to run
"update venue set name=new_name,date=new_data..... where id=original_venue_id"
original_venue_id keeps track of which row is being edited in venue table
Table 1 : venues
Table 2 : temp_venues
event 1 : user edits the venue
step 1 : store the user id and venue in temp_venue
step 2 : show temp_venues entries to admins
event 2 : admin approves the venue
step 1 : copy row from Table temp_venues
step 2 : insert row in Table venues
step 3 : delete row from Table temp_venues
I have a nested (hierarchical) kendo grid and I'm performing a batch edit on it. But my problem is when I will create new record I will not be able to save the sub details only the details of the parent row.
Example:
----------------------------------
FirstName LastName
----------------------------------
Jack Mesh
----------------------------------
Subject Code
-------------------------------
English 101
Math 111
When I click save changes, only Jack Mesh will be save. The subjects which supposed to be the sub details are not saving along.
Is there a way I could manipulate this to be able to get the parent row with its sub rows?
Thank you.
Skip to bottom to avoid long-winded explanation
Ok, so.
I'm working on a company intranet for managing client jobs. Jobs are comprised of Elements: an example element might be "Build a six-page website", or "Design a logo".
Each element consists of a collection of role-hours, so "Build a six-page website" might include four hours of "Developer" rate and two hours of "Designer" rate (ok, maybe a little longer :)
Obviously, different clients get different hourly rates. And, although that's already accounted for in the system, it's not giving us enough flexibilty. Traditionally, our account managers have been rather... ad hoc... with their pricing: the "Build a six-page website" element might include the standard four hours of developer for client "Bob", but eight hours for client "Harry".
Bear with me. I will get to actual code soon.
Elements are, of course, stored in the "Elements" database table - which is composed of little more than an ID and a text label.
My work-in-progress solution to the "we need client-specific elements" problem is to add a "client" field to this table. We can then go through and add any client-specific versions of the available elements, tweaking them to taste.
When the account managers go to add elements to their jobs, they should only see elements that are either (a) available to anyone - that is, they have a NULL client field, or (b) specific to the job client.
So far, so SELECT WHERE.
But that isn't going to cut it. If I add a second "Build a six-page website" element specifically for Harry, then an account manager adding elements to a job for Harry will see both the standard version, and Harry's version of the element. This is no good. They should only see the standard version if there's not an applicable client-specific version.
Ok... soooo: as well as adding a "client" field to the elements table, add a "parent element" field. We can then do something magically self-referential involving joining the table to itself, and fetch only the relevant roles.
My long-awaited question is thus:
Oh look, an actual question
id label client parent_element
1 Standard Thing NULL NULL
2 Harrys Thing 1 1
3 Bobs Thing 2 1
4 Different Thing NULL NULL
Given this table structure, how can I write a single SQL query that will accept a "client ID" parameter and return:
For client ID 1, rows 2 and 4
For client ID 2, rows 3 and 4
For client ID 42, rows 1 and 4
For extra bonus points, the results should include the parent element label. So for client ID 1, for example:
id label standardised_label client parent_element
2 Harrys Thing Standard Thing 1 1
4 Different Thing Different Thing NULL NULL
SELECT mm.*, md.label AS standardized_label
FROM mytable md
LEFT JOIN
mytable mc
ON mc.parent_element = md.id
AND mc.client = #client
JOIN mytable mm
ON mm.id = COALESCE(mc.id, md.id)
WHERE md.client IS NULL
Create an index on (client, parent_element) for this to work fast.
See SQLFiddle.
I'm attempting to store legislation inside an access database. Due to the inconsistent numbering and heading/subheading use, I was intending on storing the data in a flat table, with a "parent" column storing the ID to the heading, or the subheading, or the section text etc etc etc.
So - for instance
ID Section Parent Description
0 1 Purposes of the act
1 a 0 The purpose of this act is to:
2 i 1 Manage data efficiently
3 ii 1 Test access
4 b 0 More data goes here
would represent the data
1 - Purposes of the act
a - The purpose of this act is to
i - Manage Data Efficiently
ii - Test Access
b - More Data goes here
My issue is in using forms to effectively edit the data. The best approach (from what I see) would be to embed a form within itself as a subform - which is evidently not allowed. My intention was to have 2 new buttons - one for new item, one for new child. The latter which would create a child item and show it (and the other child items) in the subform.
Is there another way to do this?
I'd have a continuous form displaying the whole law/by-law (you should be able to format it for display in the source query); however, each section could be double-clicked on to open another form (perhaps modal) to edit the section.
Logically, you'd have controls for inserting, deleting, indenting and outdenting particular sections.
I suspect you will also want to include an "order" column for each section. Suppose you want to change the order of 1.a.i and 1.a.ii. You can't change the ID column, because it's probably an Auto-Number.
Of course, an obvious question is why not just store the law/by-law in MS Word and store references to it's location in the DB
I have a user that is dealing with an Access Database continuous forms page where they can perform a bunch of filtering and data entry.
Occasionally the user wants to be able to select a few rows from this form and paste them directly into an email. Outlook formats the data into a table pretty nicely on its own but the problem we're having is that dropdown controls from the header are included in the pasted data as you can see below:
Employee_Absences
drpEmployee drpOrgDescrip lstTimeCode txtToDate txtFromDate chkShowExcused DESCR AbsenceDate Hours Excused_Hours Time Code employee_lookup.ORG_DESCRIP ImportedDate
6/2/2009 1/1/2009 0 Bob 1/4/2009 4 0 VAC Medical 5/7/2009 4:51:31 PM
6/2/2009 1/1/2009 0 Bill 1/4/2009 6 0 VAC Medical 5/7/2009 4:51:31 PM
6/2/2009 1/1/2009 0 Betty 1/4/2009 4 0 VAC Medical 5/7/2009 4:51:31 PM
6/2/2009 1/1/2009 0 Beth 1/5/2009 2 0 VAC Gamers 5/7/2009 4:51:31 PM
The user doesn't want to bother with deleting and reordering columns every time they want to include a couple rows in an email and it would be fairly unfriendly to force them into a separate report or datasheet just to get two or three rows. I've tried messing with the order of the parameters in the query that is populating the form but this doesn't help at all.
Is there some sort of Copy-to-Clipboard event that I can hook into and do some magic to the data rows? Any other suggestions?
This is surely a layout problem on the form. Selecting rows of a continuous form should not copy the data from controls in the form header.
Perhaps I've misunderstood the problem?
It certainly is possible to put data on the clipboard. See this page:
Copy variables/control contents to memory
But for pasting into an email, you'd need plain text and the email would need to be displayed in a fixed-width font. Unless you want to write HTML, there is no easy way to format a table that will paste into a non-plain-text email. If they are sending in HTML (which they oughtn't be), an HTML table will work. If they are using RTF (and they oughtn't be), I don't know what happens if you paste HTML.
Try to figure out why the form header control is getting copied. My bet is that the user is not defining the initial selection correctly, and you teach them to do that (or engineer the subform to prevent it), you won't have to program anything -- which is the whole beauty of Access.
On another note, I don't believe in allowing edits in continuous or datasheet forms because if you need dynamic combo boxes and the like for data validation, it can lead to all sorts of problems. Instead, I use continuous and datasheet forms as lists and have a detail subform bound to the PK of the continuous/datasheet form so that when you select a record in the continuous/datasheet form, the data will appear in the editable detail subform.
I have just had too many problems with editing continuous and datasheet forms and that's why I've done that. The only exception I make for that is in an invoice-type form, where there is no good way to do it otherwise.