Using SAP B1's extra SQL syntax is there a way to access whether the current document is in add mode or update mode? I'm using this query to populate a user defined field with a user defined value. I need to adjust the logic depending on whether it is a new document or not.
You can access it using the normal UID syntax. $[$UID] In this case the OK button that changes to add / update when typing into a document is 1. You can save the following into a query and it will return the text in that button.
SELECT $[$1.0.0]
After that it's just a matter of using the CASE statement to check if it is equal to 'Update' or 'Add' or 'OK'.
Related
I know this has been asked many times, and I have tried many of the suggestions and solutions that worked for others, but I am not able to get this error to go away (please see attachment).
This is an Access application that is really just a UI to a SQL Server database, and uses all linked tables to the SQL Server database. The user opens access and they go to a form that opens a "Search", where the user selects a bunch of criteria and clicks "Apply Filter". A list of records appears that meet their criteria. They click the record they want, and a form is opened that displays the details about this record. They then click an "Edit" button that opens another form that allows them to edit certain fields. When they make changes and hit save is when this error appears. The odd thing to me, this only occurs if the user selects the first record in the Search list, but it doesn't seem to happen with the others in the list.
What I have tried is the following:
Added code on the "BeforeUpdate" and "Update Button Click" event to check "If Me.IsDirty = True Then Me.IsDirty = false" End If.
Added a datetime column to the SQL database that gets updated with a trigger ON UPDATE
Verified the database has no bit columns
Changed the "Record Locks" property on the form to "Edit Records"
None of these items made a difference.
Any help on what might be causing this is appreciated.
2. Added a datetime column to the SQL database that gets updated with a trigger ON UPDATE
This could actually be the cause of your problem - Access and Sql Server modifying the same row at the same time is causing the write conflict you see.
I'm afraid you have misinterpreted the valid advice you found.
What you want is a ROWVERSION aka TIMESTAMP column in your Sql Server table. That helps Access figuring out if a row has changed and solve write conflicts. It is fully automatic and needs no trigger.
More details (Albert always provides lots of details :p ) here:
MS Access Write Conflict - SQL Server - Me = Dirty
If this doesn't help: check if you have any other triggers, and post your VBA code for filter / edit / save.
After my Access got upgraded to Office 365 i'm starting to get write conflict issue whenever i edit a particular record. I was not getting this error in 2010 version.
Access database has 1 query used to filter out selected record for editing and 1 form (no subform). On some records i was able to update, but on some records i'm getting a write conflict. I'm using a run command DoCmd.RunCommand acCmdSaveRecord to save each record that is updated. Do you have an idea why changes are saved on some records and why a write conflict on some. There's no other users editing the record.
Thanks
Whenever I have issues with msaccess that I cannot explain, I do the following:
1-) Create a new msaccess empty file;
2-) Import all tables / queries / forms, objects to this new msaccess file
It normally solves this kind of issue.
I had this issue with some of my clients in the past; Most of the times it is resolved by applying the following instruction:
Select File > Options.
In the Access Options dialog box, select Current Database.
Under Application Options, select the Compact on Close check box.
Select OK.
Close and reopen the database for the option to take effect.
More details are here: https://support.microsoft.com/en-us/office/compact-and-repair-a-database-6ee60f16-aed0-40ac-bf22-85fa9f4005b2
You might have a bit field in your table that allows NULL, making it a triple-state field. Whenever you attempt to save your record, if it is null, it can raise this "Write Conflict" error.
The solution would be either to explicitly assign a value to it before saving, or use a default. Alternatively, if you have a bound control to it (like a CheckBox), set its Triple State property to False.
I am utilizing Microsoft Query in Excel to tap into an ERP table structure like Crystal would do.
In writing the SQL, is there a way to have a filter pulled from the active Excel worksheet that is embedded in the SQL instead of prompting and editing the query?
My main problem is a Like [Prompt]% in the Excel GUI for the users to change like order numbers.
Is it possible to do an off page reference from MS Query to Excel?
If by "Microsoft Query", you're talking about the window that looks like it was coded for Windows 95, stop using it. This is provided for retro-compatibility.
Anyway, if you've displayed the criteria bar in MS query, you can type a name between brackets e.g. [Something] and MS query will prompt you to fill a value.
Not what you want yet but getting close. When you return to Excel and refresh the query, the prompt will now offer you the possibility to use a cell instead of a value you need to type every type.
In the more modern connection utility accessible via menu data > Connections (+ available even if you created your table via MS Query btw), you can achieve that by using question marks in the WHERE clause.
For instance, instead of SomeField = 'SomeValue', write SomeField = ?
Then, click on the Parameters button and you'll see all the parameters you've set, each of them can be attached to a cell's value.
The problem I'm running into is quite easy to recreate.
In Crystal Reports Developer I add two different tables:
The full table "Users"
A Command containing SELECT * FROM Users
In the Field Explorer I add a new parameter and set this to dynamic. I have this parameter pull it's data from any field in either of the two tables (doesn't matter). Of course making sure the parameter is used in the record select.
If I now preview this report (in Developer) it works perfectly. I get a popup allowing me to select data from whatever field I selected in the parameter.
Using this report in Crystal Viewer it prompts for database username and password.
It seems it only does this when the same report contains both a dynamic parameter and a command. Removing the SQL command (leaving only the table) and the report works as expected.
Does anyone know how to resolve this, or is there some workaround?
I have created a simple form in Powerapps which has a text input field called name and a data table which shows a list of all customers from a table called customer in a SQL Server database and I have also added a button labelled "Go" on the form.
What I want to do is:
See a blank data table when I first open the form
I would enter a customer name in the name text input field
Click the "Go" button and then the value from the name field will be passed to the SQL Server database in a query which only returns
the records which have the same name
Display the results of the query in the data table.
How can I do this?
Thanks
Assuming you've been able to correctly add your on-premise SQL server as a data source:
You'll want to use a combination of Collect() and Filter()
Assign your user input to a variable using (this isn't strictly necessary)
GetContext({UserVariable: TextInput.Text})
Use a combination of Collect() to store the data you pull from MSSQL, and Filter() to, well, filter the data.
Collect(AppStorageTable1, Filter('[dbo].SqlTable]', ColumnName1 = UserVariable))
If you assign AppStorageTable1 as your data source for your data table, it should now appear. (Note, you'll have to declare/create it before it will appear as an option, but once you've used the name in Collect() it will appear as a data source).
EDIT: The term you likely were looking for is "delegable", a quick search will yield a few articles about it. The "Filter" function will pass the work off to your SQL server, so your app won't be responsible for processing/filtering the data.