B
bilbo baggins
Anyone have any experience in setting up VSS with Access 97.
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.
O
Ofer
Yes, tried both, VSS and PVCS.
PVCS gave me trouble with big MDB's, didn't save all the changes, but was
great with small MDB's
VSS, was great with both, no trouble at all.
I could track who made the changes, when and what. with the ability to
RollBack to a prev version
Two people couldn't update the same module/form/report/etc at the same time.
I feel like a walking advertisment, but I had good experience with it as a
team leader, I can't say the same about the rest of the team, every time
somebody said that he/she didn't do it, I was able to track exactly when it
was done and by whome
PVCS gave me trouble with big MDB's, didn't save all the changes, but was
great with small MDB's
VSS, was great with both, no trouble at all.
I could track who made the changes, when and what. with the ability to
RollBack to a prev version
Two people couldn't update the same module/form/report/etc at the same time.
I feel like a walking advertisment, but I had good experience with it as a
team leader, I can't say the same about the rest of the team, every time
somebody said that he/she didn't do it, I was able to track exactly when it
was done and by whome
A
Albert D.Kallal
Gee, a97 is 4 versions old, and a 5th version since 97 is in beta right
now..
I can't remember, but I don't know if a97 ever did support VSS.
It *might*..but it has been so long. That software is now 9 years old.
I certainly know that access 2003 with the VSS add in works...
You have to download the VSS add in for ms-access 2003 to use it however
(and, that add in don't work with a97..that is for sure).
You can find info about the a2003 VSS add in here:
http://support.microsoft.com/kb/837136
You need Visual Source Safe 6 for the above....
now..
I can't remember, but I don't know if a97 ever did support VSS.
It *might*..but it has been so long. That software is now 9 years old.
I certainly know that access 2003 with the VSS add in works...
You have to download the VSS add in for ms-access 2003 to use it however
(and, that add in don't work with a97..that is for sure).
You can find info about the a2003 VSS add in here:
http://support.microsoft.com/kb/837136
You need Visual Source Safe 6 for the above....
O
Ofer
Yes , Access 97 did support VSS
G
Guest
There is a small problem with form properties for bound fields:
they are not created when you get a copy of a form from source
control.
That is, if you have a bound field "idx", and no control called
"idx" and you are using "me.idx" to refer to the field, your
code will fail.
Loading a large database is very slow while it is connected
to source control. Access checks the status of every object
when you open the database. (It sometimes fails during this
step).
Source control is sometimes unstable when used with large
databases: you may not be able to create the database from
source control, or update some objects.
VSS is irritating: it labels all of the objects as com binary
objects, so you can't use the very good text comparison
tool! You can switch the project interface over to text,
but as soon as some one connects Access, VSS switches
the project interface back again.
You need to remove workgroup security to use source
control.
Access doesn't support source control of the tables, relationships,
or data. After the queries, modules, forms and reports are
stripped out, everything else goes in as a single binary object.
(david)
they are not created when you get a copy of a form from source
control.
That is, if you have a bound field "idx", and no control called
"idx" and you are using "me.idx" to refer to the field, your
code will fail.
Loading a large database is very slow while it is connected
to source control. Access checks the status of every object
when you open the database. (It sometimes fails during this
step).
Source control is sometimes unstable when used with large
databases: you may not be able to create the database from
source control, or update some objects.
VSS is irritating: it labels all of the objects as com binary
objects, so you can't use the very good text comparison
tool! You can switch the project interface over to text,
but as soon as some one connects Access, VSS switches
the project interface back again.
You need to remove workgroup security to use source
control.
Access doesn't support source control of the tables, relationships,
or data. After the queries, modules, forms and reports are
stripped out, everything else goes in as a single binary object.
(david)
A
Albert D.Kallal
That is, if you have a bound field "idx", and no control called
"idx" and you are using "me.idx" to refer to the field, your
code will fail.
That makes sense. However, you need to change your development approach
here.
Note that if you just change the recordsouce of the form in code, that above
me.idx will also fail (especially of the new recordsouce does not have that
field).
You SHOULD NOT be using that syntax to reference data that is NOT bound to a
control. So, you likely have potential bugs and problems in your code if you
been using that approach. This will actually mean that your "reference" will
sporadically disappear (what happens if you set the reocrdsouce of a form to
""). The "me." syntax requites the ability to resolve at compile time. Since
you do NOT have a control on the form, then you can't be assumed that the
code *will* compile if you change the data source of the form. This opens up
your code to breakage (and, bet you often wondered why the me. reference
would break). Since I have a good deal of code that actually "sets" the
datasouce of a form, then I can't reliability use the "me." syntax, I have
to use me!.
So, for bound controls, I ALWAYS use me., but for data only references, you
need to use me! (bang) notation, since you can't be assumed of the control
on the screen. (this also means when you look at my code, the dot notation
means that the control MUST BE on the screen.).
So, I guess I never been bit by the VSS problem, but then again the
"natural" approach to coding kind of pans this lesson out anyway. You can
always tell an application that had this problem when you see in the corner
of the form a whole pile controls that are not used for display, but clearly
used ONLY for code that use the me. syntax. (that the developer found was
breaking!!). So, this is not really only a VSS problem, but general problem
that is solved by changing ones coding practices. If your reference does
NOT need to work with the control, then there is NO reason to use
the dot notation, and as mentioned, it can actually go out of scope anyway.
BANG notation works regardless if the contorl is on the screen or not.
Hum,...at least with a2003, I can work just fine on a secired database.
Well...ok, what actaull happens is that when you check out a table...you
lock all of
them!!! (so, it is a all, or nothing affir).
However, any development platform has this problem. If you are
developing in VB, you can't check out the sql server tables anyway. So, a
fair point..but not a huge one, and one that no source code control really
solves anyway.
I would love to be able to check out the tables. In fact, what VSS does
right now is check out ALL tables for you!!! So, if I check out one table,
then all tables are locked. This "all or nothing" makes sense, since
changing
relationships, or other things could potentially effect all tables). And, we
are forgetting that 99% of the time, we have a split database anyway, so the
tables are not actually there, and are linked...
So, sure..there are some cavets...but not really any diffent then if you
used VB and JET, or c++ and JET anyway....
"idx" and you are using "me.idx" to refer to the field, your
code will fail.
That makes sense. However, you need to change your development approach
here.
Note that if you just change the recordsouce of the form in code, that above
me.idx will also fail (especially of the new recordsouce does not have that
field).
You SHOULD NOT be using that syntax to reference data that is NOT bound to a
control. So, you likely have potential bugs and problems in your code if you
been using that approach. This will actually mean that your "reference" will
sporadically disappear (what happens if you set the reocrdsouce of a form to
""). The "me." syntax requites the ability to resolve at compile time. Since
you do NOT have a control on the form, then you can't be assumed that the
code *will* compile if you change the data source of the form. This opens up
your code to breakage (and, bet you often wondered why the me. reference
would break). Since I have a good deal of code that actually "sets" the
datasouce of a form, then I can't reliability use the "me." syntax, I have
to use me!.
So, for bound controls, I ALWAYS use me., but for data only references, you
need to use me! (bang) notation, since you can't be assumed of the control
on the screen. (this also means when you look at my code, the dot notation
means that the control MUST BE on the screen.).
So, I guess I never been bit by the VSS problem, but then again the
"natural" approach to coding kind of pans this lesson out anyway. You can
always tell an application that had this problem when you see in the corner
of the form a whole pile controls that are not used for display, but clearly
used ONLY for code that use the me. syntax. (that the developer found was
breaking!!). So, this is not really only a VSS problem, but general problem
that is solved by changing ones coding practices. If your reference does
NOT need to work with the control, then there is NO reason to use
the dot notation, and as mentioned, it can actually go out of scope anyway.
BANG notation works regardless if the contorl is on the screen or not.
You need to remove workgroup security to use source
control.
Hum,...at least with a2003, I can work just fine on a secired database.
Access doesn't support source control of the tables, relationships,
or data. After the queries, modules, forms and reports are
stripped out, everything else goes in as a single binary object.
Well...ok, what actaull happens is that when you check out a table...you
lock all of
them!!! (so, it is a all, or nothing affir).
However, any development platform has this problem. If you are
developing in VB, you can't check out the sql server tables anyway. So, a
fair point..but not a huge one, and one that no source code control really
solves anyway.
I would love to be able to check out the tables. In fact, what VSS does
right now is check out ALL tables for you!!! So, if I check out one table,
then all tables are locked. This "all or nothing" makes sense, since
changing
relationships, or other things could potentially effect all tables). And, we
are forgetting that 99% of the time, we have a split database anyway, so the
tables are not actually there, and are linked...
So, sure..there are some cavets...but not really any diffent then if you
used VB and JET, or c++ and JET anyway....
G
Guest
OK further notes: :~)
Like you, I use the bang notation for unbound fields.
I still have invisible controls on my forms - I use them
for debugging otherwise unbound fields!
When you work on a secured database in 2003, are all
the objects given the default security settings for new
objects? SaveAsText doesn't save the security settings
of forms.
There is no way to SaveAsText a single table.When you
use SaveAsText on the database object, you get the entire
database as a binary object, so it is actually saved to source
control as a single binary object.
But since 2003 supports XML tables, XML tables in
source control could now be done if MS wanted to make
the effort. Particularly useful for Front End links and
tables, but in our case also useful for tracking the tables
and small amount of sample data in our Back End.
In SQL Server, we do this with scripts, including some
large scripts with data, but since we only have around
five records in a typical table, not extremely large scripts.
(david)
Like you, I use the bang notation for unbound fields.
I still have invisible controls on my forms - I use them
for debugging otherwise unbound fields!
When you work on a secured database in 2003, are all
the objects given the default security settings for new
objects? SaveAsText doesn't save the security settings
of forms.
There is no way to SaveAsText a single table.When you
use SaveAsText on the database object, you get the entire
database as a binary object, so it is actually saved to source
control as a single binary object.
But since 2003 supports XML tables, XML tables in
source control could now be done if MS wanted to make
the effort. Particularly useful for Front End links and
tables, but in our case also useful for tracking the tables
and small amount of sample data in our Back End.
In SQL Server, we do this with scripts, including some
large scripts with data, but since we only have around
five records in a typical table, not extremely large scripts.
(david)
A
Albert D.Kallal
I still have invisible controls on my forms - I use them
Yes...you make a great point!!! In fact, while I was making
the case that things
can break if you don't use bang..in fact you many
cases do want things to break! (so, my argument goes both ways!!).
As a coding practice, in some cases the reverse practice of placing a
control on the form means that if you remove the control, then code will
break...and that exactly what some want to happen!!
Yes...the above is the case, and your rightly point out the problem.
I did at least want to point out that you can work on a secured database
with VSS..but you CAN NOT change the security of existing objects.
So, your point about not being able to work on a secured database needs some
clarification., You can work on one..but any changes to security on the
objects can NOT occur while it is under source code control. And, it makes
sense that new objects receive the default..and it also makes sense that you
can not change existing objects security..(since, as you
mention there is NO provisions for this...and yes, you rightly point out the
"saveastext" is how this works. So security settings can NOT be saved via
VSS..and thus they can't be changed (however, existing settings are not
touched).
..
To be clear here, the this means that to modify the security settings, you
need to have everything checked back in..and then remove the application
from
source control (in a2003...if you do a compact and repair...you can remove
it at that point).
So, you *can* work on a secured database, but it is certainly hampered, and
you are MOST fair to point this out....
Hopefully security has been setup before you start working the application
with VSS. And, further, any individual changes to objects in the
application cannot be done while under VSS.
At the end of the day...it think it is quite nice that VSS does work with
a2003. And, the add in provides a UI extension, so that you actually "see" a
check mark, or a lock icon beside each object in the database (I don't know
if previous versions of access had this ability...as I never used VSS with
anything else but a2003).
Here is a few screen shots...and you can see the "check mark" that VSS add
to all objects in access for things I have checked out (and, a lock for
things checked in).
http://www.members.shaw.ca/AlbertKallal/vss/index.htm
for debugging otherwise unbound fields!
Yes...you make a great point!!! In fact, while I was making
the case that things
can break if you don't use bang..in fact you many
cases do want things to break! (so, my argument goes both ways!!).
As a coding practice, in some cases the reverse practice of placing a
control on the form means that if you remove the control, then code will
break...and that exactly what some want to happen!!
When you work on a secured database in 2003, are all
the objects given the default security settings for new
objects? SaveAsText doesn't save the security settings
of forms.
Yes...the above is the case, and your rightly point out the problem.
I did at least want to point out that you can work on a secured database
with VSS..but you CAN NOT change the security of existing objects.
So, your point about not being able to work on a secured database needs some
clarification., You can work on one..but any changes to security on the
objects can NOT occur while it is under source code control. And, it makes
sense that new objects receive the default..and it also makes sense that you
can not change existing objects security..(since, as you
mention there is NO provisions for this...and yes, you rightly point out the
"saveastext" is how this works. So security settings can NOT be saved via
VSS..and thus they can't be changed (however, existing settings are not
touched).
..
To be clear here, the this means that to modify the security settings, you
need to have everything checked back in..and then remove the application
from
source control (in a2003...if you do a compact and repair...you can remove
it at that point).
So, you *can* work on a secured database, but it is certainly hampered, and
you are MOST fair to point this out....
Hopefully security has been setup before you start working the application
with VSS. And, further, any individual changes to objects in the
application cannot be done while under VSS.
At the end of the day...it think it is quite nice that VSS does work with
a2003. And, the add in provides a UI extension, so that you actually "see" a
check mark, or a lock icon beside each object in the database (I don't know
if previous versions of access had this ability...as I never used VSS with
anything else but a2003).
Here is a few screen shots...and you can see the "check mark" that VSS add
to all objects in access for things I have checked out (and, a lock for
things checked in).
http://www.members.shaw.ca/AlbertKallal/vss/index.htm