A coworker in accounting was complaining about how she ran a query twice and it doubled her values and she got confused. Im just a Junior IT person who has very little VBA experience. I am basically just trying to add code to make it so my queries in our databases can't be run more than once unless you restart the database. I was thinking of doing a boolean check to see if a query has been run and if it has don't allow it to be run again. Or maybe I could just do a simple if statement. Please let me know if you have any input on this issue.
I couldn't find anything on the Googs either.
I would think on a date and a session ID as default values in each table, you could code the addition of both etc.
These are populated, date =date() as default value and sessionID is the DMAX from your SessionID table, as extra column in said query.
This SessionID table is incemented by a startup popup form, running macro.
The Primary Key of each table being operated on would be the date and the sessionID not allowing dupes. You probably dont need the date, just a sessionID in the PK.
It is not always the best idea to implement ad-hoc ideas by users like this.
You should analyze what happened here, and make sure it cannot happen in the application design, not by arbitrary rules.
Example: If the update query adds fees to a bill, and this must happen only once per bill, then the update query should also set a flag "fees added" in the bill record. And it should not update bills with this flag set.
Related
I am after advice more than I direct answer or if someone has done something similar. I will try and explain what I want to do. I am want to create a SQL a stored procedure that checks against table and dynmically runs the code that is situate in one of the fields, something similar to SQL Alerts but I dont want to create lots of alerts. My table would have something like an Alert Name field and a piece of code that checks to see if an order has been put in a table for over £150 as an example, there will be lots of other similar small pieces of code. This table would be linked to another that dictates how often it runs depending on the time of day then a futher table that says what happens when the alert is triggered, a stage one alert would be an email a stage 2 would be a text. I then have a stored procedure that runs constantly checking the necessary tables to see if anything needs to be run. I appreciate this might be a little vague for a direct answer but if anyone could offer some advice that would be much appreciated.
Hi DMason/Others, sorry I was typing that out a little late last night and yep vagueness seemed to be the order of the day ;) I am trying to put together a custom alert system that uses a Stored procedure to analyse a table to see if an alert is scheduled and then run it. Right I have a table that contains 2 columns Name and Code, Name is just a piece of text and Code will contain a basic select statement as an example. I then have a table of schedules for the alert this will show day of the week and time e.g. working day or other. My next table shows Thresholds for example for an alert the threshold might be 2 e.g. the original select statement cant return any more records than 2 otherwise the alert is triggered. I also have an alert level table, this means that if an alert has only been triggered once in a specific piece of time and alert goes out as an email if it gets triggered again then a text messages is sent out. There is a final table that contains things like email addresses and mobiles associated with each of the alerts. I have the design more or less put together in my head but just trying to think of the best way to put it all together or if anyone has done something similar...Hope that gives a little more detail :)
Thanks...P
Good Day,
I need some assistance please. I am rebuilding a third party Access database after it's catastrophic failure and the failure of the 3rd party developer to fix his mess. I am an avid Access Developer and know my way around an Access Database well. I am not a super VBA coder, but I can do more than my bit in VBA as well as a few other languages.
Currently, I have a database test bed with a login form that stores 3 values as public variables (gstrLevel as String, gstrUser as String, gintID as Integer). I am able to set my own "permissions" with ease in that once they login I can use the values to control the switchboard etc.
My problem now is the following. We have people recording prospective client interactions and interviews. As part of the process, every time they make contact, they record this into the database and in the process a "followup date" is created. This works like a charm. What I now need to do is warm the users if these followup dates are close or have passed so that prompt action can be taken lest we lose a prospective client.
I have a query that takes the prospective table information, and the notes table information (where the followup date is stored) and then filters the dates correctly. This in turn has been used to create a continues form to display the records that need followup soon. What I cannot seem to do is to get it to only show the logged in users followup records.
I should note that the user/agent field is a lookup field in the prospective table, and thus also creates a combo box in the Followup form. I can lock the form from changes etc, but I can't seem to get it to only display the relevant user/agent details.
I have tried:
DoCmd.ApplyFilter
Me.Filter
Me.FilterOn = True
DLookup as criteria
Using my public variables directly as query criteria
And a few other weird combinations with no success.
My problem, I believe, is the fact that the user/agent is a lookup field, and I am not sure how to filter based on that fact. If I use the gstrUser variable directly I get a type mismatch and if I use gintID directly it shows nothing.
Any ideas or advice would be greatly appreciated.
You probably have a Users table, with a numeric Primary Key (PK), while your gstrUser stores the userName.
So in the source of your Followup form, just add the Users table (joined to the Prospective table on UserId) and apply the filter on the userName field in the Users table (or whatever it's called that matches the contents of gstrUser).
I have one table called "EmployeeHours" where I have following columns:
Agent_Name Agent_Number Start_Date Time State Duration week Team
Under State column I have "After Call", "Training", "Lunch", "Tea Break" etc. Out of these "After Call and Training" are considered work hours and others are "Non work Hours". I want to add a column to this table which does this identification of work and non work hours.
I know How to do it in Excel: I have done it using the IF OR condition but I am facing difficulty in doing the same thing in MS access..
Anyone knows how to implement this IF OR Criteria in MS access and prepare that column?
Any help will be appreciated.
Something you can do that does not fully normalize your database but still gives the functionality you are looking for is to create a mapping table where you will have the different states ("After Call", "Training"...) and another field where you will have its correspondance to Work / Non work hours.
When this is done, you can create a query to calculate the Work / Non work correspondance by putting both tables in the query and linking on the Status field.
If you want you can also take this opportunity to create a table "State" with the different states in text format and with a uniquely identifying surrogate key (think Autoincrement) and replace the values in your current table with those. That way you will not sure as much text in your database (lighter) and you will be able to change the description at a single place instead of all the occurrences if you ever need to.
In a stored query, table calculated column, or form control you can use the IIF() function.
IIF([State]="After Call" OR [State]="Training", "Work hours", "Non work hours")
I have a table that has ordernumber, cancelled date and reason.
Reason field is varchar(255) field and it was written by many different sales rep and really hard to group by the reason category I need to generate a report to categorize cancelation reasons. What is the best way to analyse the reasons with TSQL?
Sample of reasons entered by sales rep
cust already has this order going out
cust can not hold for item Called to cancel order
cust doesn't want to pay for shipping
wife ordered same item from different vendor, sent email
cst made a duplicate order, sent email
cst can't hold
Cust doesn't want to go through verification process so is cancelling order
doesn't ant to hold for Bo
doesn't want
Cust called to cancel the order He can no longer get the product he wants
cnt hld
will not comply with export req
cant' hold
Custs request
Cust will not hold for BO
per. cust. request.
BTW I have SQL Server 2005.
part of your problem is that this these aren't truly reason codes. sounds like an issue with your schema to me. if there aren't predefined reason codes to reference and you're allowing free text entry for each reason, then there's really no way to do this directly, outside of pulling distinct reasons back, which is probably not going to be very useful.
just an idea, can you add another column to the table, even if it's in a temp or test environment and then give the business users the ability to assign a code (e.g. 1 for mis-ships, 2 for duplicate orders, 3 for wrong item etc.) to each order cancellation. then perform the analysis on that.
i assume that's what they're expecting from you, but i don't know that i see any better way. you could always perform the analysis yourself if you have the authority/knowledge but this might be painful if you have a ton of cancellations.
edit- i see now that you've tagged this with regex... it would be possible to setup specified keywords to pull out the entries, but there'd have to be some tolerance built in and still manual analysis afterwards for items which don't fall into any specified category due to misspellings etc. /edit
+1 to #jmatthews, you really need to have reason codes that are selected and then possibly allow free-form entry for the full reason.
If this isn't an option you can look into text clustering. Don't expect that to be fast or easy though, it's still an open research topic and is related to both AI and machine learning.
Look at Term Lookup in SSIS, here is an article to read.
What do I gain by adding a timestamp column called recordversion to a table in ms-sql?
You can use that column to make sure your users don't overwrite data from another user.
Lets say user A pulls up record 1 and at the same time user B pulls up record 1. User A edits the record and saves it. 5 minutes later, User B edits the record - but doesn't know about user A's changes. When he saves his changes, you use the recordversion column in your update where clause which will prevent User B from overwriting what User A did. You could detect this invalid condition and throw some kind of data out of date error.
Nothing that I'm aware of, or that Google seems to find quickly.
You con't get anything inherent by using that name for a column. Sure, you can create a column and do the record versioning as described in the next response, but there's nothing special about the column name. You could call the column anything you want and do versioning, and you could call any column RecordVersion and nothing special would happen.
Timestamp is mainly used for replication. I have also used it successfully to determine if the data has been updated since the last feed to the client (when I needed to send a delta feed) and thus pick out only the records which have changed since then. This does require having another table that stores the values of the timestamp (in a varbinary field) at the time you run the report so you can use it compare on the next run.
If you think that timestamp is recording the date or time of the last update, it does not do that, you would need dateTime fields and constraints (To get the orginal datetime)and triggers (to update) to store that information.
Also, keep in mind if you want to keep track of your data, it's a good idea to add these four columns to every table:
CreatedBy(varchar) | CreatedOn(date) | ModifiedBy(varchar) | ModifiedOn(date)
While it doesn't give you full history, it lets you know who and when created an entry, and who and when last modified it. Those 4 columns create pretty powerful tracking abilities without any serious overhead to your DB.
Obviously, you could create a full-blown logging system that tracks every change and gives you full-blown history, but that's not the solution for the issue I think you are proposing.