A couple of months ago I created and published over 50 reports. Each report used a stored procedure that accepted parameters.
Now when I try to create a new report with a stored procedure VS doesn't want to play nice. Instead of reading the parameters and fields of the stored procedure and populating the corresponding tabs in the DataSet properties, I am now encounting a new window titled "Define Query Parameters".
I even went back tried creating a new report with an old stored procedure (that still works in my old report).
What's changed in VS? Why is it all of sudden prompting this new window and how do I make it go back to the previous behaviour?
This happens to me sometimes. I don't know exactly why, but it seems to have to do with Visual Studio needing some dummy parameter values so it can test your stored procedure and get a sample output so it knows what fields to expect. Maybe it tries some dummy values on its own and if they work it doesn't have to ask you, but if it doesn't, it has to ask you to provide them.
What I do know is that when I get that "Define Query Parameters" dialog box, if I just type in some valid dummy values and click Ok, it works fine, lets me finish building the dataset, and I can finish building the report in peace.
So to summarize: I don't exactly why, but this isn't a setting that changed in VS. The potential for it to happen has always been there, but it only happens sometimes, and you just have to deal with it and move on.
Related
I am trying to use PXDatabase.Delete to remove specific row(s) in a Custom table or even just to get it to fire off. Here is the code that I am trying to get running:
PXDatabase.Delete<SSINHoldRule>(
new PXDataFieldRestrict<SSINHoldRule.inventoryID>(18));
When I watch SQL profiler for this code to get executed, nothing shows up in the SQL profiler which means that this code is not hitting the database. I have different variations of the above code but to avail. Any help would be appreciated. I am running this code via the TestSDK.
Generally, this would be considered direct DB manipulation, which is frowned upon by Acumatica (Documented within Acumatica certification guidelines) and should be used as a last resort. Is there a reason this is not working with general DAC record manipulation? We want to assess using that before considering a more brute force methods such as PXDatabase.Delete.
I'm working on a pre-existing python code-by-zapier zap. The trigger is "Code By Zapier; Run Python". I've made some changes to the contained python script, and now when I go to test that step I run into the following error message:
We couldn’t find a run python
Create a new run python in your Code by Zapier account and test your trigger again.
Is there any way of figuring out what went wrong?
I'm guessing a little bit, but I think this issue stems from repeatedly testing an existing trigger without returning a new ID.
When you run a test (or click the "load more" button), then Zapier runs the trigger and looks through the array for any new items it hasn't seen before. It bases "newness" on whether it recognizes the id field in each returned object.
So if you're testing code that changed, but is returning objects with previously seen ids, then the editor will error saying that it can't find any new objects (the can't find new run pythons is a quirk of the way that text is generated; think of it as "can't find objects that we haven't seen before).
The best way to fix this depends on if you're returning an id and if you need it for something.
Your code can return a random id. This means every returned item will trigger a Zap every time, which may or may not be intended behavior.
You can probably copy your code, change the trigger app (to basically anything else), run a successful test (which will overwrite your old test data), and then change it back to Code by Zapier and paste your code. Then you should get a "fresh" test. Due to changes in the way sample data is stored, I'm not positive this works now
Duplicate the zap from the "My Zaps" page. The new one won't have any existing sample data, so you should be able to test normally.
As you can probably take out from the title, I have a problem on my CRM environment converting a fax entity to an incident (case), it is as you know an out of the box functionality. When I press the button on the ribbon to convert it to a case, I'm given the following error: "You must save the changes before you can convert this activity". And I have definitely saved everything before I do this.
I do have the latest rollup and it works for the other activity entities except from this one. Is there any chance someone had similar issues? If so could you share how you resolved this. Thanks in advance.
There is likely some code running on the form that updates one or more values on the page automatically. Code like that will cause the form to become "dirty". Which is what triggers the message you are seeing.
One way to solve it, is modify your code to perform a save after it make its changes.
i am new in ms access. Now i have to finish some modifications in ms access 2003. I am getting this error "you do not have access to the database this time. If you proceed to make changes,you may not be able to save them later". Please help me to solve this problem.
Microsoft has documented the problem, but the sugested solutions were completly unusable in most of my situations. Furthermore the issue occurs even in a split database and it occurrs inconsistently with forms and controls that use code. In my opinion MS got this wrong or at the very least documented incompletly.
Here is my solution:
The problem in many instances traces back to Access thinking the DB is in an exclusive mode, when it should be in a shared mode. Setting the DB to "shared mode" under Options doesn't help, because it will revert back to "exclusive" any time a user turns on the "design view" for any object in the database OR makes code modifications OR if a user presses "save" (CTRL + S)!
In order to prevent the error message from poping up, you need to prevent the users from pressing "save" or switching to "design view" in your DB. I have deleted the save button in the Quick Access Toolbar (so users don't see it) and under Options>Current Database I have unchecked "Allow Full Menus". Additionally you can also uncheck "Enable Layout View" in the same menu.
Possibly the Save function can be disabled alltogether, but I have not yet written code for this. This solution is not fool proof, but it greatly reduced the occurence of the problem in my various split and unsplit DBs.
I was getting this error in ms-access-2010 just the other day. I was working with a method in vb to query the db. I needed to commit my transactions and close the database object after I was done with it at the end of the method. This fixed the problem for me.
This occurs in Access 03 when you are not the only live user present in the .mdw (security) file, if this is a shared database then before making any changes you will need all other users to log out and then to ensure this error doesn't occur again, always open the database in 'exclusive' mode for editing, this is achieved by selecting the little arrow on the open button.
However, you can also have some strange behaviour with .mdw files, if you are genuinely the only user logged in, then I would suggest first logging out, manually deleting the .mdw file if it exists and then going back into the database.
Always open the database in "exclusive mode" when programming and this will never happen.
I inherited an very old application that I am in the process of updating it (I know, we should have rewrote it in VS 2008, but we purchased a company, which is how I was stuck with the relic). Using UpdateData(TRUE) to retrieve the changes made in the dialog controls, nothing is being updated. I have an edit control, with an integer variable, and an edit control with a string variable, assigned using the class wizard. Upon pressing the OK button, the UpdateData(TRUE) is executed to retrieve the new values from the disalog.
I seem to remember having a similar problem back when VS C++ 6.0 first came out, but have not used it since VS 2003 and C# became prevalent.
Thanks for any help in advance!
Bill
Check the DoDataExchange() method. It should have the logic for writing data to or reading it from the controls. If the programmers used the default implementastion, then there will be a DDX_... macro for each control that is being read/written. Just look at any other MFC dialogs (in your code or google) to see how the DDX commands should be written if they are missing.
Alternatively, if it's only 1 or 2 values you can easily just get the control and read it directly if you don't mind doing validation etc yourself. Get the ID of the control from the form designer and use something along the lines of:
CEditWnd *pWnd = GetDlgItem(ID_THECONTROL);
CString newValue = pWnd->GetWindowText();
...
You'll need to look at the content of the DoDataExchange method and see what it is doing. There is not sufficient information here to tell what could be going wrong other than that.