I asked about setting up an in-memory dataset with TClientDataset, and was told I had to use the "Create Data Set" command in the form designer. That works just fine until I try to create a master-detail database relation. If I have a field def of type ftDataSet, then running the Create Data Set command (or calling the method at runtime) gives an "Invalid Field Type" error. I did a few searches and found that other people have had this problem before, but nobody ever seems to come up with an answer. Does anyone know how to fix this?
Instead of putting your detail in a ftDataSet column, just use a unique integer or GUID for the key reference, and place the detail data in a different TClientDataSet and have that key. Like you would in a normal database. Each TClientDataSet representing a different table.
If you create a field of type ftDataSet, you need to define the dataset, else the type is not valid.
You can define the dataset, by:
select the field.
select the ChildDefs property and click the [...] button.
add the fields.
Now you can create the dataset. Unless one of the children is of type ftDataSet in which case you have to recursively repeat the process.
A nasty problem that cost me a lot of time already. Finally I found a workaround, described here (Thanks you guys!):
http://www.delphigroups.info/3/6/171869.html
Summary: The culprit are the field definitions of the master client dataset, i.e., the one that contains the ftDataset fields. As soon as the field definitions of the master client dataset are not empty, the command CreateDataSet fails with the above described error message ("Invalid Field Type").
Workaround:
Create master-detail tables as instructed, but make sure the field definitions are empty when doing CreateDataset:
a) Designtime: Before you do "master dataset | RightClick | Create DataSet" in the design form, you have to click on the master dataset, go to object inspector, click on FieldDefs, and delete all the fields in the FieldDefs window. (The very first time you built the master dataset there are none in there anyway, but later there are.) Only then do Create Dataset. (I tried this myself with Delphi 2007; it works.)
b) Runtime: Call [Name of Masterdataset].FieldDefs.Clear before you do [Name of Masterdataset].CreateDataSet. (I did not try this out myself, but it is credibly described in the above named link.)
If this was too complicated, please look in the above mentioned link.
Related
Hope you're well. I'm currently building out a report, but despite my best efforts so far, I can't get some information to populate within the report. It does not appear to me that salesforce is recognizing the field "Agent Incoming Connecting Time" within the object "AC_Agent_Performance". However, I can pull in some other fields within the same object into the Agent Performance report, so I'm not clear on what is not taking place in the field that I wish to see within the report. Here are some of the things that I've tried:
I have checked the access to the field. The first photo (Photo 1) Shows an example of a working object, the the second one shows an example of one that does not.
The API name seems to work, and is consistent with other fields within the object that work.
I have checked the page layout for the object (even though I don't think this is the issue), and I have mirrored other fields to the best of my knowledge that ARE populating within the report.
I reviewed the CTI flows to see if there was something missing in there on a lark, but there was nothing in there that would lead me to believe that this was the source of the problem.
I have tried setting up a new field in the object (formula), that references the field that I'm trying. to pull in, but that just returns a result of 'zero' for all values.
One thing that I have done that appears to be working, is I have set up a joined report, which uses both "AC Agent Performance" object and "AC Historical Queue Metrics" object in the report. The result that is returning appears to be accurate (please see the picture (picture number 3)). However, I don't think that this is the right way to go about this, and I don't want to do it this way. I want to use the report with one object rather than with two.
I know that permissions are the most likely issue, so I've taken a close look at these. Please let me know if there is something wrong with how I have the permissions configured. The First image depicts the 'Field Level Security'. The second image depicts the'field accessibility'. They are both like this, the whole way down:
Please note one other thing, which is that the last picture depicts a different field within the object displaying in the report.
Does anyone have any ideas on how I can proceed so the field "Agent Incoming Connecting Time" will display within the report?
Please also note, that these are objects that contain data that is populated from AWS' Amazon Connect.
This last photo, shows that the object does not have any information in it within the report.
If the field isn't populated there's not much you can do on the reporting side of things. You already tried "joined report". You should check why the integration doesn't populate it, maybe read integration documentation, contact the managed package's support...
The tables are connected with lookup or master-detail, right? In a pinch you could try making formula field on "AC Agent Performance" looking "up" and pulling the value from related AC historical queue metrics. If the relationship is other way around (performance -> down to related list -> metrics) you could try to make-do with a master detail and rollup summary field. I don't know this package, no idea if you can pull it off when you don't have full control over the fields.
If you can't really use the relationships and absolutely need to report on single table - you could capture intermediate results of the report to a helper table and then report on that. It's called "reporting snapshots". Or write some nightly (hourly?) batch that recalculates stuff and writes homemade "rollup" to these fields?
Epicor - what a beastly creature!
Epicor asking for password after making a table change, any idea why?!?!
We removed the relationship from the (part table) and set up a criteria, instead. Now it is asking for a password, which should not be happening.
the login happens when I try to run the report. I am trying to figure out what I did to aggravate Epicor. The table was already there. I removed the relationship (part table) and added a criteria, instead, otherwise, that is exactly what I would have done. The only reason that I did not add a table to a report data definition, like I originally wanted to is because the parts table could only be added once. Which is why I removed the relationship and added a criteria, instead.
From your description, it sounds like the problem is related to the xml generated by Epicor for a non-BAQ based report data definition. Crystal and SSRS reports ask login information when either there is more than one datasource is referenced in the report, or there is improper relationships defined.
Note:
If you are not a report developer and you have modified this in an attempt to change the end data, I recommend you contact the report developer responsible for maintaining these before proceeding. Otherwise, read on.
Based on my experience, I would say if you are confident in the new relationship structure you have in the report data definition, the solution to this problem is likely within the report itself. Generate an xml file by running a test report, then open the .rpt (or .rdl) associated with this report and set the datasource to the new xml file. This should update the new xml schema used as the datasource. Even if none of the fields were changed in the data definition, the datasource schema definition that is stored in these files define exactly the data formatting that the report expects to receive when it is opened by Epicor.
If that doesn't solve the problem and you are using Crystal, the xml relationships may be defined in a way that will effect the way the data is displayed, which can be adjusted by using database expert->links tab in crystal. You should reconnect all of the links to match the report data definition within Epicor.
If none of that works, open up and view the xml file.
It is not unheard of for report data definitions in Epicor to break behind the scenes when altering relationships, and the xml file generated by the test report may not be a fully-qualified xml file. I have seen many xml files that do not have elements closed, etc. that will cause various problems when attempting to run the report. In this case, my recommendation is to create a completely new report data definition (do not copy), and re-enter all of the parameters that existed in the former definition. Repeat the refreshing of the report datasource as described above and this problem should be fixed.
An Access form (called FFF, let us say) is linked to a SQL Server table via a DSN-less connection.
Everything works OK.
There is a field on the form called (for the sake of argument) XXX.
The bound control (i.e. the SS data name) is also called XXX.
Usually, it shows data correctly, and allows updates.
Occasionally, when XXX is referred to in VBA code behind the form, such as
"IF XXX > somevalue THEN ..."
an Access error occurs, with the number -2147352567 and the description "Could not find field."
It doesn't name the field that can't be found, but the error line is the line mentioned above, which refers only to the field XXX.
I have tried extending the field reference by using Me.XXX, or Forms!FFF!XXX, but the problem remains.
The client PC is running MS Access 2010 runtime.
There are no Access (Jet) tables involved.
Can anyone suggest how to fix this error, please?
Access can occasionally get confused when a Control on a form has the same name as the Record Source field (column) to which it is bound. This can sometimes lead to strange behaviour similar to what you've described.
For example when we drag and drop the field LastName onto a form we get a text box whose .Name is "LastName". Under those circumstances VBA code referring to Me.LastName is actually ambuguous: Are we referring to the field [LastName] in the Row Source, or are we referring to the control on the form with the same name? In many cases it doesn't matter, but sometimes it does.
The solution is to rename the control. A common convention is to add a prefix to the control name based on the type of control: txtLastName for a text box, cbxCategory for a combo box, etc.. That clears up the ambiguity because Me.LastName is the field, and Me.txtLastName is the control.
Setup
I have a Master-Detail relationship, and on the master, I sum up a field from the Detail object.
Question:
I need to allow the user to check a box on the master object which will add the sum by 1 or decrement by 1. How do I do this?
Here's what I've tried:
In an after update trigger on the master increment/decrement within the trigger. Of course I get an error:
expected exception, contact your administrator: NonCashCompAfterUpdate: execution of
AfterUpdate caused by:
Created a new field, and used the existing field as a helper. Basically, I've hidden the old RFS while still using it. This works, but I wanted to see if there was a better way.
Before I went any further I wanted to check in for ideas.
Thanks!
There is no way to directly alter values on a roll-up summary field in salesforce, except by altering the underlying detail records. The second proposal, as I understand it, would involve three fields, the roll-up summary, the checkbox, and the displayed summary (which would be a formula field). The displayed summary field would look something like this:
Rollup_Summary_Field__c + IF(Checkbox_Field__c, 1, -1)
The read-only nature of a roll-up summary field is preserved in Apex as well, so you would not be able to alter it through a trigger. Presumably, that is the nature of the error that you got, though the excerpt that you have attached omits the actual error.
I have a SQL database where one of my fields 'Status' has one of 10 entries in it (not from a dropdown list). I let some people have access to the data through an Access database, they can add and modify entries.
My question is, in Access, how can I make it so that the 'Status' field is a drop-down list from which the users can choose from (the 10 entries which are already in the SQL database)? It would be easier for them and also mean that mistakes cannot be made.
Many thanks
Scott
The usual way to do this is to use a combo box on a form with the row source taken from the look-up table and the bound column set to the field (column) of the table to be updated.
In Access you can add lookup information to a column. That will automatically display a dropdown list.
Step 1: Start the lookup wizard:
Step 2: After the wizard, the lookup settings should look like this:
Step 3: When your users open a table, they should see the dropdown box:
In addition to the solution described by Andomar you must not use another table as the source for your lookup. You can also provide the lookup-values in a list, which is hardcoded in the table-definition. This is fine for simple scenarios where the lookup is something that is not likely to be changed.
Several issues here:
table datasheets are not suitable user interface for users.
you can create a saved QueryDef and if you view the properties of a field, the second tab is just like the second tab in table design, and allows you to use a combo box as your display type in your query. I would generally recommend against this, as, like table datasheets, a QueryDef is not a proper UI element, and if you use the saved query in other queries, you can run into the same problems that cause lookups in table fields to be such as bad idea.
you're building a UI, so use the tools that Access provides you for building a UI. That means a form. Your form's recordsource would have the bare data, and you'd create a combo box on your form that is bound to the field in the table behind your form, and displays the values from the lookup tables. There's a wizard to step you through this. If you like the look of datasheets so much (column sizing, sorting, show/hiding are all features that are nice in datasheets), you can set your form to display as a datasheet.
My advice is that for building a user interface, use the tools Access provides for creating user interface. In my opinion, a dropdown list belongs in a form, and nowhere else. While I occasionally might add one to a query for quick-and-dirty editing, I would never do that in objects that users are going to use.