Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | have parameterized queries without user interaction | ||
---|---|---|---|
Product: | Base | Reporter: | ldegener <afblukas> |
Component: | code | Assignee: | AOO issues mailing list <issues> |
Status: | CONFIRMED --- | QA Contact: | |
Severity: | Trivial | ||
Priority: | P4 | CC: | issues |
Version: | OOo 1.1 Beta2 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | Linux, all | ||
Issue Type: | ENHANCEMENT | Latest Confirmation in: | --- |
Developer Difficulty: | --- |
Description
ldegener
2003-06-27 12:13:10 UTC
assign to bh and set target huh? LDegener, can you please be more specific than "with the content of user text fields or something similar"? What functionality do you need? BH->MSC: Please don't set target milestones for Feature / Enhancements. valid objection, IMO. Untargeting. (->Frank) Sorry, for beeing vague. This is propably related to issue 16146 and maybe also 16147 I need a way to express an association of certain data records to a certain document. So for instance if i write a letter to a customer who's db record id is xyz, i want to have all relevant queries (i.e. those containing a customerID column) filtered by customerID=xyz. This seems to raise two questions: -How do i store the customerID persistently within the document ?(see Issue 16147) My first guess here was to use user TextFields, but it seems that FieldMasters which don't have any Fields attached aren't saved with the document. -How do i parameterize the queries, so that a user browsing the datasource browser while editing the letter only sees those query results that are related to that customerID? The natural aproach seems to be adding "customerID=:parm" to the WHERE clause of the query, but instead of popping up a dialog asking for the value parm, OOo should substitude this automaticaly with contents of a user text field named "parm" Replace "user text fields" with anything that solves the problem above. Maybe the whole "Parameterized Query" approach is inadequate. In this case, see Issue 16146. Ah - I understand now what you mean, thanks :). Out of my head, I indeed think that Issue 16146 may indeed be a better solution (because what you suggest here is very specific, while a solution for issue 16146 would allow for other nice things, too), but this may be wrong ... Hmmm. Yes, maybe close the file on this one. It seems to be a semantical problem, which is IMHO better adressed by issue 16146. change subcomponent to 'none' To grep the issues easier via "requirements" I put the issues currently lying on my owner to the owner "requirements". |