Can't I work on a copy of the database while others are using the
production model? If I change a form in the copy, I'll copy the changed
form to the production model - yes - after everyone has gone home. Or
perhaps before they've come in. So, when you say, "You can't make changes
to the forms and code while users are working in the application if you
don't split" - is that really a true statement?
Well, lets not get into splitting hairs on a level of semantics here.
it is essentially correct. However, when you split, you also are working on
a copy.
The problem is not so such working a copy, but keeping track of the changes
and fixes you make. I mean, if you spend a whole day making changes, and
additions to your application, you could have changed 12 forms, the layout
of 5 reports..and code in a dozen different places. and, we not even talking
about sql quires you modified. While you *can* keep track of this, it
certainly a bit tedious and VERY easy to miss something you changed.
That tracking is a waste of time and effort that you could be using to
further your application ahead. Also, if you forget one thing to copy in the
middle of code routine, then your likely to spend the day tracking down a
bug.
You going to need all the effort, talent, and focus that talent on creating
a really good product. Splitting simply allows you to do that. You spend a
whole day developing new features for that application, and you now going to
have to somehow remember all of the changes you made? (as I said, it is
possible..but it also very easy to miss one thing you changed. further,
importing forms means you have to delete existing ones, and it rather easy
to mess up that process. And, when you have to copy code, it not only easy
to miss something, but can introduce bugs...
Ok, this is valuable to me. I didn't know I could develop in a split
environment. I thought I had to complete the app and then split it.
Hum, this is unfortunate. You not only want to develop in a split
environment for reasons of performance (or seeing bad performance, but you
also want to learn about re-linking tables in your start-up code etc. You
eventually will have to build in your own linking code. (but, for now, the
linked table manager will become a common tool you use).
I used to test on a 10baseT network, and deploy to a 100baseT network. I did
this, as you want to work in a system that is sensitive to performance
issues. If your system BARELY works good when it is on a single user
machine, and un-split, and then you deploy to a network, that is too late.
it means you might be using 99% of the network ability, and then when you
add two users...you in big trouble performance wise.
We don't split at the start of development (as my article states).
So, it not only you want to split, but you frequently want to test and
develop in that split environment so you have a feel for how the application
will run in that environment.
I think I've explained this. If you see that my plan is unworkable I'd
appreciate hearing why - without the insults.
My apologies here. I did state that I being a bit of a advocate. I just
trying to developers out that other developers viewing this would have a
negative reaction here. I meant in no way to make this personable to you.
Please accept my sincerely apology if this came off the wrong way. However,
I think that your "sense" of my reaction is exactly what I wanted to convey
to you. however, I look for NO license here to be rude, or disrespect. It is
not my intention.
Anyway, back to how to update?
Sure, copying forms, code etc is a possible solution. If you spend the time
tracking, or writing down (or whatever) each fix and change, and thus build
up a list of things that you must change (import) to the production mdb,
then it is a possible solution. I do think this introduces a point of making
mistakes, and forget things.
However, how much of a future battle do you want to prepare for? How great
of product do you want to make here? These tips and hits are not things that
you *must* do, they are simply things that make the developer process go
better.
So, like a good pool player, it not they are a super shot with the pool cue,
but they learn to *avoid* the difficult shots. (that is the real secret to a
good pool player, or software developer).
so, splitting not only follows how most software is deployed, but it gives
many other advantages also.
The problem really you faced with is that you did not spend a significant
amount of time developing as split, and on a network. Hind sight is so
rather easy ad pathetic on my side here. (I mean, rally...so what...we
learning things here!!). So, what!!, we are dealing with after the fact, and
I not trying to flame you, or but heads with you.
The other big feature of splitting is that you can deploy a mde in place of
a mde. that mde has the source code removed (no tampering from your users -
forms and code design is locked), the mde is also smaller, and does run a
bit faster because debug code and source code is removed.
So, what would I do now?
Well, I would try working your way though Tony's list if things to check,
and see if any helps.
if none of Tony's list helps, then you now kind of stuck between a rock and
hard place. Since you have something that seems to be limited in
performance. You either run un-split, or see if improvements can be made in
performance.
I should note that we often see weekly posts in the sql server newsgroup
when a person takes the mdb back end, and moves the data to sql server, and
expects performance to increase, and in most cases...it does not. Ms-access
makes a great front end to sql server, but the migration and lessons learned
is similar to your case (you want to have a good portion of the development
and testing process to be simular to that of your production environment).
Good luck..and do feel free to ask more questions...
