How can I make my own delete method to prevent that the data really gets deleted?
I want to set a datetime field when it gets deleted instead of a normal delete.
I read about overriding the submitchanges function, but I don't get it to work
Handle SavingChanges, go through the deleted items in the context, change their state to modified, and modify the field in question.
I wrote an interface IRequiredColumns with the properties CreatedOn, ModifiedOn and DeletedOn which every entity implements. Then I created this partial class for the context:
Partial Public Class Context
Public Overrides Function SaveChanges(ByVal options As System.Data.Objects.SaveOptions) As Integer
For Each entry As ObjectStateEntry In ObjectStateManager.GetObjectStateEntries(EntityState.Added Or EntityState.Modified Or EntityState.Deleted)
If TypeOf (entry.Entity) Is IRequiredColumns Then
Dim entity As IRequiredColumns = CType(entry.Entity, IRequiredColumns)
Select Case entry.State
Case EntityState.Added
entity.CreatedOn = Now
Case EntityState.Modified
entity.ModifiedOn = Now
Case EntityState.Deleted
entry.ChangeState(EntityState.Modified)
entity.DeletedOn = Now
End Select
End If
Next
Return MyBase.SaveChanges(options)
End Function
End Class
This works great for me!
If you won't find out how to override the delete function, you can create an ON DELETE trigger for every table in database, that does not delete, but sets datetime field.
Related
I’m building an Access database with classes e.g clsOrder, clsCustomer etc which manage the interface with tables. These classes create instances of forms when displaying their data. I found that once the execution of code was within one of these forms I couldn’t refer to the parent object that created it (so is there a better way of doing this? would be part of my question).
To deal with this I’m using a scripting dictionary to store instances of classes with a key using the ID of the class and a unique identifier for the class (e.g Order-3265). I then store a reference to the owner object in the form itself.
So when an object is created and its ID is known it puts a pointer to itself in the dictionary and gives that pointer to its form (hope that’s clear enough).
This then allows the form to interact with its owner class.
I’m using another class clsManager to do the adding of items to the Dictionary or retrieval or removal (with destruction).
Examples of classes - seriously cut down..
clsManager:
Public WorkingObjects As New Scripting.Dictionary
Public Function AddWorkingObject(key As String, ObjectType As Object) As Boolean
If Me.WorkingObjects.Exists(key) Then
Me.WorkingObjects.Remove key
Me.WorkingObjects.Add key, ObjectType
Else
Me.WorkingObjects.Add key, ObjectType
End If
End Function
Public Function GetWorkingObject(key As String) As Object
If Me.WorkingObjects.Exists(key) Then
Set GetWorkingObject = Me.WorkingObjects(key)
Else
Set GetWorkingObject = Nothing
End If
End Function
Public Function DestroyObject(obj As Object) As Boolean
Dim key As String
If Not obj Is Nothing Then
key = obj.DictionaryKey
If Me.WorkingObjects.Exists(key) Then
Me.WorkingObjects.Remove (key)
Set obj = Nothing
If obj Is Nothing Then
Debug.Print key & " destroyed"
Else
Debug.Print obj.DictionaryKey & " NOT destroyed"
End If
End If
Set obj = Nothing
End If
End Function
clsQuote:
Option Compare Database
Option Explicit
'use a form using an instance of this class to control manipulation of Quote records
'Loading and saving set default values if a null value is detected
Private Const scTABLE As String = "tblQuote"
Private intID As Long 'unique identifier
Private intCustomerID As Long
Private intSiteID As Long
Private rsQuoteTotalValues As DAO.Recordset
Private oCustomer As clsCustomer
Const ObjectType = "Quote-"
Private oEditForm As Form_frmQuote
Property Get EditForm() As Form_frmQuote
Set EditForm = oEditForm
End Property
Property Get ID() As Long
ID = intID
End Property
Property Let ID(QuoteID As Long)
intID = QuoteID
Me.EditForm.ID = QuoteID
End Property
Property Get Customer() As clsCustomer
Set Customer = oCustomer
End Property
Property Let CustomerID(ID As Long)
intCustomerID = ID
oCustomer.Load (ID)
EditForm.SiteID.RowSource = oCustomer.AddressSQL
EditForm.SiteID.Requery
EditForm.ContactID.RowSource = oCustomer.ContactsSQL
EditForm.ContactID.Requery
EditForm.CustomerID = ID
End Property
Property Get DictionaryKey() As String
DictionaryKey = ObjectType & CStr(Me.ID)
End Property
'END PROPERTIES//////////////////////////////////
Public Sub DisplayForm(Visibility As Boolean)
With Me.EditForm
.Visible = False
.subFrmQuoteSectionsSummary.SourceObject = ""
If Visibility = True Then
...some stuff...
.Visible = True
End If
End With
End Sub
Public Function Load(ID As Long) As Boolean
'On Error GoTo HandleError
Dim RS As DAO.Recordset
Dim sQry As String
Load = False
If Nz(ID, 0) <> 0 Then
sQry = "SELECT * FROM " & scTABLE & " WHERE ([ID]=" & ID & ");"
Set RS = Manager.DB().OpenRecordset(sQry, dbOpenForwardOnly)
With RS
If .RecordCount = 0 Then
MsgBox "Cannot find Quote with ID = " & ID, vbCritical
GoTo Done
End If
Me.ID = Nz(!ID, 0)
Me.CustomerID = Nz(!CustomerID, 0)
Manager.AddWorkingObject Me.DictionaryKey, Me
Me.EditForm.SetOwnerObject (Me.DictionaryKey)
.Close
End With
Set RS = Nothing
Load = True
End If
Done:
Exit Function
HandleError:
MsgBox "Error in Customer Load: " & vbCrLf & Err.Description, vbCritical
Resume Done
End Function
Private Sub Class_Initialize()
Debug.Print "Quote class initialized"
Set oCustomer = New clsCustomer
Set oEditForm = New Form_frmQuote
Me.ID = 0
Set oQuoteTidier = New clsClassTidier
Me.DisplayForm (False)
End Sub
Private Sub Class_Terminate()
Set oCustomer = Nothing
Set oEditForm = Nothing
Debug.Print "Quote class terminated"
End Sub
From the EditForm:
Option Compare Database
Option Explicit
'necessary for the object to have a reference to its owner in this manner to prevent circular reference
Private OwnerObject As clsQuote
Public Function SetOwnerObject(OwnerKey As String) As Boolean
SetOwnerObject = False
Set OwnerObject = Manager.GetWorkingObject(OwnerKey)
SetOwnerObject = True
End Function
Private Sub cmdClose_Click()
OwnerObject.EditForm.Visible = False
Manager.DestroyObject OwnerObject
DoCmd.Close acForm, Me.Name
End Sub
Each business object class (like ClsOrder) has an editForm instance which is loaded and hidden until required and a up to 3 DAO Recordsets that it keeps open.
I think all references to the business objects that are interrelated are pointers to the objects in the dictionary.
My problem is error 3035 exceeding system resources. I’ve checked objects are destroyed when not in use but repeatedly opening and closing objects gets me to error 3035.
So the question is- am I just asking Access to do stuff it can’t or would better programming fix it?
I see ZERO reasons to write all that code. Why not let a form handle all of this? Remember, each form is in fact a "class" instance. You can even launch multiple copies of a single form, each with their own code, own data and each instance of the SAME form can operate 100% independent of other working copies of that same form.
If you attempting to look at this problem and wanting to have a class object for a form, then just use the form object - that's what it does for you!
I see zero benefits from writing all that code. While .net has the dataset manager and system (and now the very similar entity framework, this is MUCH done since .net does not have data bound forms.
In Access, each form is in fact a class object. And that includes any public sub or function for that form (so functions become methods of that form, and public vars become properties of that form). In addition to the bound form having a truckload events, these events work as actions against any data editing. So, unlike most systems, you have "on change" event, before update event, after update event. So, by simply adoptiing a bound form, then you get:
A class object is automatic created for you.
You can have multiple instances of that class, and hence multiple instances of that same form open at the same time.
You get all of those data events that can be used for verifiction of data input (or have the user not save the record until such time your critera is met.
You have full use of all data columns, even if controls are NOT placed on the form bound to those columns. So, you even get intel-sense for all of the data columns - that is you map.
I am not aware that there is some big huge circular reference problem here. This is like stubbing your toe, but then going to the doctor for some huge open heart by-pass operation. So to go on some huge massive coding spree, and chew up huge amounts of developer dollars for some "rare" issue of some kind of rare and un-seen circular reference issue is essentially a huge wild goose chase that will only have you chewing up huge amounts of developer code and time when NONE is required at all.
I mean, if you have say 3 instances of the SAME form open? Then how does the code know and refernce what insance of that form? Well, the EXACT same approac used in typical OO programming can and should be used here. That approach means you don't HARD CODE the forms! name or referances in code EVER. You never want to do this.
So, if you are in a sub form, and need to referacne say data or controls in the parent form?
You could do this:
strLastName = forms!frmCustomer!LastName
In above, we have hard coded the forms name. You don't want to do that.
In that subform, the correct way to write this code is:
strLastName = me.Parent.form!LastName
Now, note how the above referances the parent form. So, that code will work EVEN if we have 3 copies of the frmCustomer active at the same time. You can full refernce ANYTHING in a form by its object "instance". So, in JavaScrip, or c#, you often see "this.SomProperty" as a refeance to that object.
In access, you can do the same thing, and use "me". Or me.Parent.From to reference the parent form. So, as a general approach here, you should NEVER have to hard code forms reference. If you take this approach, then all issues of circular referencing will not only be eliminated, but then you are using a classic and traditional approach to object programming, and object referencing. While Access is not full OO, it certainly follows a lot of OO design concepts, and how forms work in Access are most certainly instances of a object.
Attempting to write truckloads of code when the forms object model already exists as a "single" class object instance of that form makes no sense, and is not required, and the road you going down will likely hamper and reduce your abilities to deal with the fantastic instance of that form you already have.
As noted, the form already has the dictionaly and columns attached, and Access EVEN generates the members for your automatic. The result is you can reference any column of the table that the form is bound to with
me.LastName
me!LastName
While the above two formats are allowed, the first (me + dot + column name) is in fact a member of the forms class. You will find that if you use code to set the forms data source, then often these members are NOT generated for you, and thus you have to use the ! (bang) to reference columns from the table for that form.
So, I don't grasp while you attempting all that extra code when the form has all of the abilities you are asking for in a class object.
I have 2 different user account type and they both are stored in their respective tables (Members in Member table and Admin in Administrator table). Now i want to create a common function to access user info for any type of user, so i was looking a for generic function but i am stuck with returning respective class, I have create 2 class MemberInfo for normal users and AdminInfo for Admin usersNow if the generic class passed to this function is MemberInfo than it should process normal user details and return MemberInfo class, and if it's admin users, then it should return AdminInfo class.
Here is something what i have tried but unable to achieve my goal.
Public Function GetAllMembers(Of T)(ByVal accountType As AccountType) As List(Of T)
Dim T_ReturnValue As List(Of T)
Dim returnType As Type = GetType(T)
If returnType Is GetType(MemberInfo) Then
Dim _list As New List(Of MemberInfo)
With New OleDbDataAdapter("SELECT ACCOUNT_NO, COUNTRY FROM Member", Globals.DatabaseConnection)
Dim dt As New DataTable
.Fill(dt)
For Each row As DataRow In dt.Rows
Dim memberInfo As New MemberInfo
memberInfo.AccountNo = row("Account_No").ToString
memberInfo.Country = row("Country").ToString
_list.Add(memberInfo)
Next
End With
Return DirectCast(_list, List(Of T))
End If
End Function
Can anyone help me how i can return respective class, for now i wanted to return memberinfo class only.
Two ways:
You can have two overloaded functions that return different classes.
You can declare the function as Object, and return either class.
You can follow these steps.
Create an abstract class say "User" . And then Member and Admin has to extend that base class user. Assuming, both has same set of properties and that is why you have started using T to make it generic. But as you have said both has different DB table store.
If you different methods defined for Member and Admin, you can segregate them by using interface. Say Member can Send Friend request, so you can have an interface ( Say ISendRequest), that will have Send method definition only. And if Admin can Add new member ,then you can have interface say IAddMember, and Admin will implement IAddMember , Member will implement, ISendRequest.
KEY point Now, define an interface say IGetAllUser with method GetAllUser and User class has to implement that, but it will have abstract method GetAllUser. So point here is you have to have to write this one GetAllMembers, instead each derived class will have method to get corresponding List .
Sample code snippet. This can even accommodate the scenario if both Member and Admin has different properties.
But if you have same properties, then you can define a function in Base class, that takes Datatable and just sets required properties, as both member and admin has same properties. So the sole purpose of GetAllUsers implemented in Member and Admin class is to pass required table name to Data Access layer and get DataTable and pass that to function defined in base class to set required properties and build List of User.
public interface IGetAllUsers
{
List<User> GetAllUsers();
}
abstract class User : IGetAllUsers
{
public abstract List<User> GetAllUsers();
}
class Member : User
{
public override List<Member> GetAllUsers()
{
// Assuming there is data access layer, to get details
}
}
class Admin : User
{
public override List<Admin> GetAllUsers()
{
// Get all admin
}
}
Right. Before addressing your specific question, I want to start at the lower level.
In theory, an admin is a user, so at database level this should rather be implemented so that there is a [Users] table that stores all kinds of users including admins. Then you should add another table called [Admins] which links to the [Users] table through an FK and stores all additional fields that relate to admins only. This is called ISA / inheritance relation in RDBMS theory.
At application level, this will translate to two business classes, one for [User] and one for [Admin], where [Admin] will inherit from [User] class. You can then write a function that returns a [User] object. Since [Admin] inherits from [User], polymorphism will allow you to return [Admin] object from the same function. Then your caller can confirm the returned object type either through type checking, or you can store a boolean field in [Users] table called IsAdmin that will be true for administrators.
I have a WebForms applicaiton using the new ASP.NET Identity. I've added a couple of additional fields in the class to allow for Email and a Boolean called IsOnLine.
I use migrations, to explicititly update the tables, and can see that my new fields are there. However, whenever I try to login now i get the following error:
Additional information: The 'IsOnLine' property on 'ApplicationUser' could not be set to a 'null' value. You must set this property to a non-null value of type 'System.Boolean'.
All the exmamples on the net relate to MVC, which i'm not using yet.
How can i fix this?
A bool cannot be null so that is what is set to in the database. If you want it to be null you will need to define it as a nullable bool using the ? operator.
public class ApplicationUser : IdentityUser
{
public bool? IsOnline { get; set; }
}
To update this information in the database take a look at this article on adding email confirmation to ASP.NET Identity. In this example there is a boolean flag IsConfirmed that is updated during the registration process, which will be similar to your IsOnline flag. Here is a snippet of the relevant code to update the database.
user.IsOnline = true;
DbSet<ApplicationUser> dbSet = context.Set<ApplicationUser>();
dbSet.Attach(user);
context.Entry(user).State = EntityState.Modified;
context.SaveChanges();
I prefer to avoid null values whenever possible, to determine if a property can accept nulls values it is better to think what that information represents in the domain problem. In this case i think it not make sense to have an undetermined value for IsOnline because the user is online or offline, not middle terms apply to this fact.
To resolve this problem with the database, taking advantage that you are using Code Migration , you can use the Seed method from Configuration class and assing the value(s) to your new fields that are not nullable.
Pseudo code:
Seed()
for each user
set user IsOnline to false
I don't think I am asking the question correctly, but hopefully you know what I am asking.
What are pros and cons of using a string value to represent a database field (or any variable) vs using an enumeration or constant? I am not asking about the datatype, but hows its handled on the back-end. I'll use LINQ to SQL for an example.
My thinking is that by using an enumerable or constant it's: easier to read, ensures compatibly should the values ever need to be changed, and the value is hard coded -so to speak- so there are less chances of an error caused by a typo. On the flip side, do I really need a class/structure with member enumerations that essentially act as a look up for the value I want?
Using an Constant
Module Trip
Public Const OPEN As String = "Open"
Public Const PENDING_PAYMENT As String = "Pending Payment"
Public Const CANCELLED As String = "Cancelled"
Public Const CLOSED As String = "Closed"
End Module
Dim product = From p In db.Payments
Where p.PaymentId = PaymentId
For Each item In product
item.Status = PayStatus.PENDING_PAYMENT
Next
Using a string
Dim product = From p In db.Payments
Where p.PaymentId = PaymentId
For Each item In product
item.Status = "Pending Payment"
Next
As one of the comments says, the common way to deal with this is using a lookup table in the database. In its most simple form, you would have a class, let's say PaymentStatus:
Class PaymentStatus
Public Property Id As Integer
Public Property Name As String
End Class
and Payment would have reference property like
Public Property PaymentStatus As PaymentStatus
This way, you can always get the options from the database and you will never make a typo in code. It's also much easier to add options or to change descriptions.
For instance, think of what you need to do if you'd decide that "Cancelled" needs to be differentiated into "Cancelled by user" (the old status) and "Cancelled by system" (a new status introduced by new business logic). You'd need a script to update all records in the database to the new string (and change the code, but you'd be changing code anyway). A lookup table allows you to update only one record (and add a new one in this example).
I have two classes in two separate libraries (one VB, one C#):
Public Class Item
...
Public Overridable ReadOnly Property TotalPrice() As String
Get
Return FormatCurrency(Price + SelectedOptionsTotal())
End Get
End Property
End Class
and
public class DerivedItem : Item {
...
public new Decimal TotalPrice
{
get { return Price + OptionsPrice; }
}
}
As you can see, the DerivedItem.TotalPrice shadows the Item.TotalPrice property. However, when trying to retrieve the DerivedItem.TotalPrice value, I'm still getting the base object's TotalPrice value.
Why is the DerivedItem's property not being returned?
EDIT
I've actually found the problem! I am getting the wrong value in the JSON string being returned via AJAX. It turns out that the TotalPrice is being returned correctly, it's just being overwritten by the shadowed property call being made later in the JSON string. My new question, then, is how to I prevent the shadowed property from being serialized?
(This question has been rescoped here)
It may depend on how you are instantiating the object.
For example:
DerivedItem i = new DerivedItem();
i.TotalPrice();
Will call the shadowed version.
However:
Item i = new DerivedItem();
i.TotalPrice();
Will actually call the base.
Here's a nice explanation.
Of course if at all possible I would avoid shadowing.... :-)
Are you referecing TotalPrice from a reference to the base type?
Item item = new DerivedItem;
string s = item.TotalPrice;
Does setting <NonSerialized()> attribute on the base class property work?