In an alternate application, the user has the ability to update their address and phone number. When these are changed, three fields will update: Old Value, New Value, and Field Changed. If the Field Changed was the address, I need to create two report pages - one with the old address and one with the new. However, if the Field Changed was the phone number, I only need to create one report page for the current address.
My initial plan was to do a Union that would have one record with the Old Value and another with the New Value. This should work when only the Address has changed. However, it won't whenever the Phone Number has changed. I assume I need to do some sort of case statement, but I'm not really sure if this is the right approach. Sorry if the data is a little confusing (I didn't design the data structure. This was provided by our professor's assistant). If you need more information, I'll try to provide it.
I'm not looking for exact SQL, but I am wondering if I'm approaching this the correct way.
What do you mean by a 1 or 2 page report? Are you outputting to a CSV, PDF, XLSX or something eles?
If you need to do this through "pure" sql I would recommend a stored procedure that is given a value stating whether it's the address or phone number that is being updated. It can then do the update and you can simply do an if statement which determines which report to run and return.
I'd recommend handling it programatically if possible. Have your code run the sql update and then call the appropriate function within your code to get the report you need. You can then easily re-use the code for that report in other ways.
Related
In my SSRS report I am attempting to incorporate entitlements. If a user puts a specific person ID in the parameter, I'd like to be able to compare it against the up to 50,000 ids they are entitled to use and to put up an error message if not.
The available values feature only allows me to use a dropdown, which is incovenient for so many ids. What are my options?
A drop down would be very inconvenient for that many choices. Is it possible to break them down by a category or something like that? You could then create cascading parameters to make the list easier to deal with.
Otherwise it would have to be a free text field. Depending on the complexity of the report contents you could handle it a couple of ways.
If it is a very simple report with just a tablix you can set the no data row value to your error message.
If it is more complex you can display the error message using two rectangles. The first one would simply contain a text box with the error message in it. Then put the actual report comments in the second box. Control the visibility of these rectangles based on an expression that checks the number of rows returned by the dataset or some other indication that the input was invalid. You may even need to create a second dataset to check for input validity if there isn't a reliable way to use your normal query.
I have a query that accepts input from a form. The query works as expected when I run it, manually typing in the form input values. However, when I run the query from the form, the query returns blank - no error, just blank.
I don't understand what's causing it - at it's most basic, the user is simply entering a Start and Stop date. I'm entering the data exactly the same, and made sure my form text box is formatted as a date.
Furthermore, when I run the form, I am not prompted for any values, so I know it's reading them accurately. This system works for several similar queries, but not this one.
What I've tried
Changing the format of the text box to specify Short Date (which is how I type it)
Visually confirming the values are making it from the form to the hidden staging area the query references - these values match what I manually enter into the prompts
The query I'm runnning references another query; running the other one by itself only yields one set of "date" prompts, not two. So I created a seperate date input box for each to read off of, but to no avail
Question: Does Access try and format (or not format) parameter input boxes differently than it would handle form references?
Additional detail - when I run the query manually, it prompts me for the dates twice - I don't know why or it's pertinent, but I thought I'd mention it.
use instead Temporary variable in your Query for the specified dates. After you select the dates from the Form, make sure that the values are assigned to the temporary variables and that you requery the record source of the form
I was able to get this working by tweaking my query in the designer - specifically by splitting up my expression into multiple pieces and writing the criteria in segments.
I'm not sure why this did the trick, but it at least got me where I needed to go.
Good luck to anyone else experiencing this!
I'm developing winform application using vb.net. I use crystal report in my application. Now i need to store the index of each record that is displaying in current report into database. Then i create another report which displays the index of all the records. My plan is to read the page number of each record and save them on database. I have a group field in the report. I don't know how to scan one by one record and get appropriate page number. I tried the following code to get the field value but did not work.
msgbox(rpt.DataDefinition.FormulaFields("name").Text)
It displayed the formula of that field.
I don't know in which order the records fetched using following.
msgbox(rpt.rows(0).item(0))
Please Help me out....
The way your question reads, it sounds like you're trying to generate an "index" for the order records appear in a report and store that index in a database for use in another report. I am not clear at all what you're trying to do with the page number.
In any case, I need to make something clear: the definition of the report (which you're accessing in your code sample) only represents where data will go when the report is formatted - it is not the actual data itself.
At the most basic level, Crystal Reports takes data out of a database and formats it nicely for you on pages. Rather than trying to take data out of a database, put it into a report, then try to read that report to put it back in a database to make another report, why not just do all your data manipulation at the database level itself before going to a report in the first place?
If you really must have that first report, the easiest option you'll have for getting at the formatted data is to export it to excel and access it programmatically through an Excel API - Crystal Reports doesn't have an API for getting at your formatted data (including things like generated page numbers, whatever you're trying to do with them).
You are trying to break few basic rules. For example a report should never change the data. The right way is to handle data processing in a stored procedure or command and to call the report in a separate process. In such way you will be able to control the data change and data visualization separately.
P.S. You probably mean "Identifier" not "Index"
I have a scenario wherein with the following details:
I have a form that contains fields like firstname,middle name,lastname,dob,pin,address for Client 1.
Now this form has to cater more than one client . The problem statement is - different clients may require different number of fields to be displayed on front end. For eg: a 2nd client would want - Country field instead of pin, would not require address on the form.
Now when i submit the form , currently i have a constant query which takes values of - firstname,middle name,lastname,dob,pin,address and inserts it into database for Client 1. I want to develop a query in a way that it is created at runtime and inserts only the values that come from the form into the database..
I hope my problem is clear. Can anyone help?????????????
You need to think about why you are doing this.
It will get hideously complex with just person form, add in more and it will balloon big style.
Dynamically building queries isn't particularly complicated, but it's a lot of code to do it.
Just think about each field you want to add to the query and it's type. What if a property on your person record was an image of them.
Do you have a configuration of the form, is the promary key on the record an auto inc, is it a compound key, do you use defaults, are some fields not null. How are you going to bubble back referential integrity exceptions...
Do the all singing all dancing version and basically you reinvent something like the Access IDE....
Personally I'd have a Person object with a set of Person Properties, they would have name, a value and a boolean to say whether they'd been changed.
Once you have teh list of chnaged properties and beacseu you are in the Person object you know the table is persons, it's keyed by an autoinc bigint, gender is mandatory and defaults to Male...
You have a fighting chance.
Your query should use parameters
So it would be say Insert Persons(FirstName, LastName, PIN) Values(#FirstName,#LastName,#PIN)
Then you'd nip through your changed fields and add parameters with same name, type and value.
As I said you can really go to town with this one, may be it's time for a night in though.
This should mean that some fields in your table like address and pin can be empty, in that case you can do without a dynamic query. Just collect all the inputs from your form and insert them into your table. Those form fields that were left empty due to different user needs will consequently have their corresponding field in your table empty. So just list all the needed fields in your table and all the possible input from your form in your insertion query.
I've been tasked with learning Lotus Domino Designer - not sure what I did in a previous life, but it must have been pretty bad... - and was wondering how to do a lookup on a database to get some values for selections. As this information could potentially be used in a lot of the applications, I'd prefer it only to be in the one place.
I gather I can use #DBColumn, but what happens if an entry in that lookup changes? If the unique value of the lookup is the text, then the relationship would be broken, wouldn't it? Is there any way of mimicing the idea of relational lookups?
I'm assuming I'm looking at Lotus development from the wrong angle, as this seems to be a real limitation of look ups.
I haven't found any decent learning material on the interwebs, so would appreciate any help.
Ta
You would want to store a unique ID along with the textual value in the source database (not unlike what you would do in an RDBMS). Then, only store that ID in any referencing documents, and use a computed-for-display field to lookup the display value. (There is a performance consideration here - and you could "de-normalize" the data and store the ID and text value in the referencing documents, and do some asynchronous work to keep the values in sync - eg: using a scheduled agent that runs every night or every week).
If DB1 has the key values and DB2 has the documents which will reference these values, then in the form in DB2, you would still do a #DbColumn to lookup your value list. In the lookup view in DB1, concat the text value and ID with a pipe separator (textField + "|" + ID) in the first column. That will tell Notes to store only the ID value (what follows the pipe is the "alias" and is what will be stored).
Note: I would avoid using #DocumentUniqueID as the unique ID for these values, as the Document Unique ID will change if the documents are copied and pasted, or the entire database is copied, etc. You can use the #unique formula function in a computed-when-composed field to generate something close to a unique ID (almost like an identity column in sql).
If you need relational properties, look for non-Notes solutions. It is possible to get some relational behavior using document UNIDs and update agents, but it will be harder than with a proper relational backend.
Your specific problem with referencing to a piece of text that might change can to some extent be resolved by using aliases in the choice fields. If a dialog list contains values on the form...
Foo|id1
Bar|id2
...the form will display Foo but the back-end document will store the value id1 - (and this is what you will be able to show in standard views - although xpages could solve that). Using the #DocumentUniqueID for alias can be a good idea under some circumstances.
It depends on where your using the data. The #DBLookup or #DBColumn will work in Lotus Notes fields if the fields are set to be computed for display. That way they always get the most up to date information when you open the form etc.
If you make it so the data is saved on to the document then you will have to write some update code when you need to refresh the values.
The Lotus Notes help files for designer are pretty good, have a look at that.
SM
You could use a key or alias to store the relationship to your lookup value so if the value itself changes, the connection remains because the alias is intact. For example, if your lookup values were being stored as a collection of documents, I'd have the #DBColumn retrieve Document UNID|lookup value pairs. When in display mode, you could then retrive the value using #GetDocField. If the lookup values are in a different database, then you'd have to retrieve them for display using #DBLookup and construct a view that is keyed off of the UNID or whatever key you decide to use.The only drawback to this technique is that you wouldn't be able to display the field value in views as the actual value isn't stored in the document, just a reference to it. Using XPages, though, you COULD map the relationship into a dynamic datatable just like you would in a truly relational system.
It's tricky, but using LEI, you could also use Notes to front-end a relational backend system, also giving you the dynamic relationship you desire in your lookups.
Hope this helps!
The content of the lookup can change freely. A problem only arises (as it would on any other platform in the same circumstances) if the lookup key changes. You need to use a key that won't change. Human-readable text is an advantage, but if you want to be able to change your key description from, say, "Divisions" to "Business Units" and still have lookups work, you need to use an alias of some kind, which will presumably be mapped to your text description and only used internally. #Unique is pretty good for this, and gives a shortish key, if that is important to you. #DocumentUniqueID is most reliable, but as Ed pointed out, will change (must change - it's a new document) if you copy/paste or make a non-replica copy. This is easy to get around, though. Create a Computed-when-composed field (called, say, "LookupRef") on the form you are using for your reference document with the formula "#DocumentUniqueID". That will capture the ID at the time of creation, and it will not change on copy/paste etc. Use that as your key.