M
mg
GhostInAK said:
LOL. Your reply demonstrates my point far better than I ever could.
You have a very low threshold for 'perfect'.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
LOL. Your reply demonstrates my point far better than I ever could.
You have a very low threshold for 'perfect'.
K
Kathy
Hi Izzy,
I was just noticing if I leave a textbox, I can get to the
bindingsource's current datarowview which has the old value as you
indicated; that is, unless I do an EndEdit. However, if I leave the
parent of the textbox (e.g. leave the tab page the textbox resides on),
then apparently an EndEdit is automatic because the current
datarowview has the new value at that point.
I should probably manipulate the data directly which I do for non-UI
related tasks. Is there a significant difference in performance
between the 2 data manipulation methods?
Thanks.
Kathy
I was just noticing if I leave a textbox, I can get to the
bindingsource's current datarowview which has the old value as you
indicated; that is, unless I do an EndEdit. However, if I leave the
parent of the textbox (e.g. leave the tab page the textbox resides on),
then apparently an EndEdit is automatic because the current
datarowview has the new value at that point.
I should probably manipulate the data directly which I do for non-UI
related tasks. Is there a significant difference in performance
between the 2 data manipulation methods?
Thanks.
Kathy
I
Izzy
Kathy,
I had a nice long respone written for you....then my stupid computer
over heated and turned off.
Anyway...here's an idea:
If this data is being stored in Access, you could insert the old data
into the history table before you run your update. This will create a
little extra duty for your database server but a very common task for
audit tracking.
I would try to avoid comparing each textbox's value with a cached
initial value too determine if changes have been made. I usually just
define a boolean property called "IsDirty" and on validating of the
textbox controls set this property to true. You can then use that to
determine if an update and insert needs to take place.
If IsDirty Then
MoveToHistory(PrimaryKey)
UpdateTable(PrimaryKey)
IsDirty = False
Else
'No Changes Detected
End If
Just curious...How big is this Access database? AND how much history do
you need too store?
Izzy
I had a nice long respone written for you....then my stupid computer
over heated and turned off.
Anyway...here's an idea:
If this data is being stored in Access, you could insert the old data
into the history table before you run your update. This will create a
little extra duty for your database server but a very common task for
audit tracking.
I would try to avoid comparing each textbox's value with a cached
initial value too determine if changes have been made. I usually just
define a boolean property called "IsDirty" and on validating of the
textbox controls set this property to true. You can then use that to
determine if an update and insert needs to take place.
If IsDirty Then
MoveToHistory(PrimaryKey)
UpdateTable(PrimaryKey)
IsDirty = False
Else
'No Changes Detected
End If
Just curious...How big is this Access database? AND how much history do
you need too store?
Izzy
K
Kathy
Izzy,
The Access app I am porting from is in use at multiple businesses where
there is a mix of databases sizes; some use Access and some use SQL
Server as backend db (hence my need to accommodate both). My users
require saving unlimited field change history (w/ old & new values, who
made the change, date/time change made, field changed, etc), so the
history can get rather large. I would prefer to capture the changes at
the same time a record gets saved versus as each field changes for
synchronization purposes. Just curious, why do you recommend against
comparing against the cached (old) values? Also, does setting IsDirty
as you suggested prevent the automatic database update until you force
it? Another contributor suggested saving the old value in each
control's Tag property. That seems workable, too. Another contributor
suggested subclassing, but I would lose the control's visibility in the
designer which I really don't want to do.
Thanks for the help.
Kathy
The Access app I am porting from is in use at multiple businesses where
there is a mix of databases sizes; some use Access and some use SQL
Server as backend db (hence my need to accommodate both). My users
require saving unlimited field change history (w/ old & new values, who
made the change, date/time change made, field changed, etc), so the
history can get rather large. I would prefer to capture the changes at
the same time a record gets saved versus as each field changes for
synchronization purposes. Just curious, why do you recommend against
comparing against the cached (old) values? Also, does setting IsDirty
as you suggested prevent the automatic database update until you force
it? Another contributor suggested saving the old value in each
control's Tag property. That seems workable, too. Another contributor
suggested subclassing, but I would lose the control's visibility in the
designer which I really don't want to do.
Thanks for the help.
Kathy
I
Izzy
I see, you need too accommodate both db's. Well....
The reason I would try to avoid comparing a controls value to a stored
old value is performance. You mentioned having hundreds of textbox's,
so it could turn into a lengthy process and sounds like it would be
maintenance intensive.
For now you will have to do whatever is timely necessary. Tag property
sounds fine. Only do sub classing if you really understand all that's
involved. Why make things more complicated then they need too be.
Moving forward...IMO, I would develop 2 versions of your app. 1 for
Access clients and another for SQL Server clients.
For the Sql Server clients I would add update, delete triggers to the
database tables and archive history that way. Or you could put this
logic in a Stored Procedure and make it a transaction. First adding to
history then update live data. This would also resolve any problems
with multiple people updating the same info at the same time.
For the Access version I would do as I suggested earlier, running an
insert too archive history then perform the update.
I'll bet since you're accommodating both SQL Server clients and
Access clients you're probably using OLEDB objects. This is another
reason to create 2 versions, this way your SQL Server clients will
benefit from SqlClient objects.
Let me know if you need any help.
Izzy
The reason I would try to avoid comparing a controls value to a stored
old value is performance. You mentioned having hundreds of textbox's,
so it could turn into a lengthy process and sounds like it would be
maintenance intensive.
For now you will have to do whatever is timely necessary. Tag property
sounds fine. Only do sub classing if you really understand all that's
involved. Why make things more complicated then they need too be.
Moving forward...IMO, I would develop 2 versions of your app. 1 for
Access clients and another for SQL Server clients.
For the Sql Server clients I would add update, delete triggers to the
database tables and archive history that way. Or you could put this
logic in a Stored Procedure and make it a transaction. First adding to
history then update live data. This would also resolve any problems
with multiple people updating the same info at the same time.
For the Access version I would do as I suggested earlier, running an
insert too archive history then perform the update.
I'll bet since you're accommodating both SQL Server clients and
Access clients you're probably using OLEDB objects. This is another
reason to create 2 versions, this way your SQL Server clients will
benefit from SqlClient objects.
Let me know if you need any help.
Izzy
I
Izzy
Also, does setting IsDirty
What automatic update? Are you talking about the dataview accepting
changes and eliminating the old value. If so...No it wouldn't
Setting up a boolean "IsDirty" property would simply let you know an
update needs to happen, data has been changed in some way. I'm sure
your doing something similar to this now? right?
How are you currently telling your application that changes to data
have happened and now an update is necessary?
Izzy
as you suggested prevent the automatic database update until you force
it?
What automatic update? Are you talking about the dataview accepting
changes and eliminating the old value. If so...No it wouldn't
Setting up a boolean "IsDirty" property would simply let you know an
update needs to happen, data has been changed in some way. I'm sure
your doing something similar to this now? right?
How are you currently telling your application that changes to data
have happened and now an update is necessary?
Izzy
K
Kathy
Izzy,
I was using the .HasChanged method.
Those are some great suggestions. Yes I was using OleDb. So you think
the benefits of using SqlClients outweighs having to maintain 2
versions? Would it be worth converting my Access customers to use SQL
Express (assuming that's free). Is SQL Express robust enough?
Thanks again.
Kathy
How are you currently telling your application that changes to data
have happened and now an update is necessary?
I was using the .HasChanged method.
For the Sql Server clients I would add update, delete triggers to the
database tables and archive history that way. Or you could put this
logic in a Stored Procedure and make it a transaction. First adding to
history then update live data. This would also resolve any problems
with multiple people updating the same info at the same time.
Those are some great suggestions. Yes I was using OleDb. So you think
the benefits of using SqlClients outweighs having to maintain 2
versions? Would it be worth converting my Access customers to use SQL
Express (assuming that's free). Is SQL Express robust enough?
Thanks again.
Kathy
B
BK
Moving forward...IMO, I would develop 2 versions of your app. 1 for
Not to fuel any fires, but.... We have all our db I/O go through a
middle tier class. The front end knows nothing of the backend. The
form sends requests for adding and updating records to the middle tier
class and that class knows what db to send things to. I can easily
accomodate ANY db this way, and in fact do. We have a mixture of DB2
(IBM iSeries), Oracle, and SQL Server. I could just as well accomodate
Access if I had to. I also have my audit trail here since all updates
come through this class.
Just my 2 cents.
Access clients and another for SQL Server clients.
Not to fuel any fires, but.... We have all our db I/O go through a
middle tier class. The front end knows nothing of the backend. The
form sends requests for adding and updating records to the middle tier
class and that class knows what db to send things to. I can easily
accomodate ANY db this way, and in fact do. We have a mixture of DB2
(IBM iSeries), Oracle, and SQL Server. I could just as well accomodate
Access if I had to. I also have my audit trail here since all updates
come through this class.
Just my 2 cents.
I
Izzy
Hay BK,
How do you tell the middle layer which database it's working with?
I've yet to write any Ntier apps and am interested in thier design.
Thanks,
Izzy
How do you tell the middle layer which database it's working with?
I've yet to write any Ntier apps and am interested in thier design.
Thanks,
Izzy
B
BK
We have a User object that is instantiated when the user authenticates
to the system that keeps track of what back end to communicate with.
That user object is handed off to every form as forms are opened.
Every middle tier business class requires a valid user object in the
New constuctor.
By using this design, we can and sometimes do give the users the
ability to redirect to a different database without logging out. We
simply force all the open forms to shutdown and then we update the user
object with new server/database information. I have one application
where they occasionally want to connect to different databases
(sometimes connecting to a local database to work offline, or to a test
database to try something without affecting production). They can
easily do this on the fly.
Does that help?
to the system that keeps track of what back end to communicate with.
That user object is handed off to every form as forms are opened.
Every middle tier business class requires a valid user object in the
New constuctor.
By using this design, we can and sometimes do give the users the
ability to redirect to a different database without logging out. We
simply force all the open forms to shutdown and then we update the user
object with new server/database information. I have one application
where they occasionally want to connect to different databases
(sometimes connecting to a local database to work offline, or to a test
database to try something without affecting production). They can
easily do this on the fly.
Does that help?
I
Izzy
Ya, thanks for the info.
Izzy
Izzy
B
Brian Tkatch
Kathy said:Brian,
I have set this up to work with either a MS Access or SQL Server
database. I think I've accomplished both issues now. Inside the LEAVE
event I'm comparing the old to the new value as suggested by Jim.
Inside the ENTER event I was storing the value in a global variable.
But I like your idea of using the Tag property for saving the old value
better than what I did. That way I can compare all the text boxes
during the binding source's CurrentChanged event. Does that sound
reasonable?
Thanks !
Kathy
Sorry for the late reply.
Yes, it does sound reasonable.
I think the Tag property is actually made for this. (Not sure what else
it's for!) As for when to compare it, it should be done anywhere after
the user has nothing else to enter, and before any updates to the table
happen. *Which* event that happens in is mostly irrelevant, unless you
want the UI to trigger (and handle) it at some specific point.
I would think to (store and) check all the fields at the same time,
however. Should be easier to maintain.
B.