none
MS Access 2013 & Source Code Control

All replies

  • At the file level: any.

    At the object level: any supporting MSSCCI (see http://blogs.office.com/b/microsoft-access/archive/2008/05/14/access-source-code-control-and-team-foundation-server.aspx)


    -Tom. Microsoft Access MVP


    Tuesday, February 05, 2013 4:13 AM
  • Thank you for your response, Tom. At the moment we're with A2007 & TFS 2010.

    I've found the following information at http://technet.microsoft.com/en-us/library/cc178954.aspx:

    Access Source Code Control - Fully removing the feature - The Developer Source Code Control is not available as an add-in for Access 2013.

    Not sure whether we can manage "file level" source code control with MS Access.


    Vladimir Cvajniga

    Tuesday, February 05, 2013 6:40 AM
  • Ah I was aware of that article but somehow this hadn't registered. I will ask about this internally.

    In our company we have been doing file-level for ages, but we don't often have 2 developers work on the same project at the same time.


    -Tom. Microsoft Access MVP

    Tuesday, February 05, 2013 2:14 PM
  • This requires a userid and password to access.
    Tuesday, February 05, 2013 4:58 PM
  • This is unfortunate. For sure access being a single file does mean you can "save" previous versions/copy with great ease. (this is what I currently do).

    However using SCC allowed resolution down to single objects and thus SCC with Access meant you were not limited to file level control.

    Note that the saveastext and loadfromtext commands STILL do exist in 2013. As a result one could very EASY cobble together something that would allow export and import of individual objects. You could even add this option to the ribbon with great ease. You would however loose the nice "UI" in Access that shows what objects are checked in or out by you. (few realize how cool this looks in Access. This screen shot shows the check box or X of objects in their current state when using SCC with Access:

     

    The above is Access 2003 running under SCC, but the effect is equally cool even with 2010.  So "locked" items are not mine, but the one module  with the check mark is checked out and owned by me.

    So the commands to distill Access objects out to single text files does exist, but perhaps simply dropping back to file level and saving copies could work.

    Seeing the "end" of SCC for Access certainly is a sad thing and does much represent a "end" of a era for Access. However, to be fair, SCC is an option used by VERY few developers and thus cries of seeing this feature go are certainly cries only to be heard in the great wilderness of the internet by experanced devlopers, but not much by the general access community.

    While few are affected by this feature being dropped, my heartfelt sympathies do go out to those who experianced using this feature with Access - it is a darn cool feature!


    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada

    Tuesday, February 05, 2013 5:19 PM
  • If only I had known it existed, I might have used it. In over 10 years of reading Access websites, forums and other documentation, I have never heard it mentioned. So I wont miss it disappearing.
    Tuesday, February 05, 2013 5:23 PM
  • Vladimir Cvajniga wrote:
    > Which source code control can be used with MS Access 2013?
     
    As it is based on SaveAsText/LoadFromText (already mentioned
    by Albert) I'm quite sure that the German tool Oasis will be offered
    (For the english version click on the Union Jack down at the right.)
     
    It is a mediator or interface between Access and popular
    version control systems like TortoiseSVN, Mercurial, Git etc.
     
    --
    cu
    Karl
    *********
    Access-FAQ (German/Italian): http://www.donkarl.com
     
     
     
    Tuesday, February 05, 2013 6:00 PM
  • As noted, it was just not widely used. From crash test (when you send information after a crash etc, then if SCC was being used, then they would receive informaton about this, and then fix code that was casuing the crash).

    These tracking systems (watson) also tell the folks in Redmon how often SCC is being used - and it is really the user community (me included) that perhaps failed to promote good use of SCC as part of the software develpument process.

    For the sake of histry - here is a cool shot of Access 2010 working with Team Foundation Server. Note the cool ribbon (part of Access) for source code control. I using "icon view" for larger icons to show off how the check mark or "lock" graphic that appears beside each time.


    As noted, the above is rather slick and as noted the Team Foundation ribbon etc. is PART of Access - just that no one uses it.  So we were not restriced to using the old Visual Source Safe (but that also works!).

    In the several years i this forum, I don't think I answered ONE question about using Source code control and versioning in Access. There is simply NO case to be made for the folks in Redmond to continue supporting an expensive option that no one uses.

    So, I much accept and respect the decision that SCC is being dropped, but I thought one last kick at the cat and sharing the above cool screen shot was a honorable and fitting farewell to something few will miss!

    Golly, is the above cool or what?

    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada



    Tuesday, February 05, 2013 9:10 PM
  • Thank you very much for pointing me to Oasis.

    Vladimir Cvajniga

    Wednesday, February 06, 2013 12:38 PM
  • Thank you very much for your input, Albert.

    The company I cooperate with is not going to use any of Microsoft development tools in future. MS applications are very buggy plus there's not much technical support. MS Access has become a toy over the years... instead of becoming a really powerfull database tool. I'm affraid MS is going to cut Access completely which is really sad. :-(


    Vladimir Cvajniga

    Wednesday, February 06, 2013 12:48 PM
  • Hi,

    I've only encountered two cases about Source Control in Access forum.

    TFS and MS Access 'New from SourceSafe' fails

    How do you remove TFS Source control from a duplicate Access 2007 file. 

    I will report this requirement internally later.

    @ Vladimir: You may send feedback to Microsoft about this requirement for Source Control via the backstage of Access 2013. (Click on the frown face.)

    Best regards,


    Yoyo Jiang[MSFT]
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Thursday, February 07, 2013 5:19 AM
    Moderator
  • Well, for support of Access? Between the forums here, and places like Utter Access, I think Access has the best community and has more support for just about any simular product.

    And my experience with these tools I used has been first rate. I cannot say using team foundation server is exactly a toy, and TFS been rock solid (runing on server 2008R2 with SQL server is not somthing I would say lacks stability - it been bullet proof for me).

    So for Access "becoming" a toy, you might have to expand a bit. I mean, Access 2010 having built in support for TFS (as the above ribbon shows) is not exactly chump change here.

    And Access 2010 received a new version of VBA (vba 7). That is the first new version of VBA in about 10 years. This new version has support for the windows 64 bit api (LongPtr). I mean, it is about time and long overdue we received a pointer type in Access VBA for the windows API. And we also have a new "long long" 64 bit wide variable type also.

    So new support for x64 bit API, and a 64 bit version of VBA in my books is not a "user" feature at all.

    And don't forget, this means we also received a 64 bit edition of JET (now called ACE).

    And Access 2010 was likely the FIRST product released from Microsoft with support for SQL Azure. Again, how is SQL server and especially SQL running on Azure not a serious developer feature?

    And then Access 2010 is the FIRST version of access to have both store procedures and table triggers (again, how is table triggers and store procedures not a developer feature?). In fact, I not aware of any muti-user file based database system + designer in the marketplace that has multi-user ability with table triggers – are you? Name any file based multi-user system with an IDE + table triggers?

    And Access 2010 was the first version of Access (including runtime) that had support for creating PDF files without requiring any updates or add-ins. So no printer driver, no 3rd party add-ins required, or a SP update like in 2007. Now I can well admit that PDF ability is also a "user" feature, but it certainly a welcome feature for developers also.

    And Access 2010 now has a native web browser control. Prior to 2010 was next to impossible to attempt to use a browser control in Access. Now with a native control, you can have a BOUND browser control in your forms. So displaying corporate pdf's, corporate pictures, catalog items  and even just documents from a company web site is done with great ease.  This control opens up use of web display data in your forms.

    And Access 2010 was the first version to allow you to drop reports into a sub form control.  After all, these days we print less and less, so being able to display reports inside of a sub form is really nice – allows for great looking dashboard types of applications.

    Share images: (this is oh so nice!)
    When you insert an image into a form , we are used to having two options
    (imbedded, and linked). You now see a 3rd new option in the combo box drop
    down called shared.  If you choose shared, then the image choice becomes a
    combo box drop down of all the currently existing images in your
    application. This means you can use the ONE same imbedded image over and
    over again in the application.  Even more cool as that this means only one a
    copy of the image exists and you can change it and thus every part within
    your whole application that referenced that shared image will also change! This not only reduces bloat, but means a change to one corporate logo will be reflected in every form and place you used it.

    So now that I pointed out a few of the new features in 2010 (there are MANY more, but I am talking about "developer" centric features, it is your turn:

    What features in say 2000, or 2003 or over the years do you feel been added that is more "developer" like then what you see in Access 2010? In other words, I see more cool and great developer features in 2010 than likely what we received in the last 5 previous versions. In other words, was the direction in Access 2002, or 2000 more "developer" then 2010?

    And as for stability? I had fantastic stability with 2010.

    I am not here looking to have some type of rock throwing contest. However, often people say, oh, golly, no new developer features in Access 2010, but then when I ask them to list out those so called developer features they WERE talking about in previous versions – not only does one fail to give me a good answer, I can clearly show that 2010 likely received more developer features then MOST new versions of Access.

    The KEY concept I am pointing out here is while you may "feel" that Access is not receiving useful developer features, looking at the list in 2010 I find it rather amazing.

    And I not even talked about the disconnected option we have with SharePoint. I been deploying SQL based Access applications for 10+ years. Now a good number of those applications are being converted and are CURRENTLY running with VBA front ends connected to SharePoint tables running on 365. (at $6 a month with great speed and reliability – I cannot believe how fantastic this option is for Access).

    So, how is table triggers, TFS support, store procedures, 64 bit editions of VBA etc, new image control with shared images all of a sudden considered non developer features?

    So, when I say I lament the passing of built in SSC in Access? Sure, I really do, but I am also a most practical person. There is just not the traffic and use of SCC in the Access community to justify the cost of maintaining such a feature when so few use it.

    Every once in an awhile a great release of Access comes along. Access 97, 2003 and now 2010 are among my favorites – and to be honest – my current favorite version at this point in time is 2010.

    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada

    Thursday, February 07, 2013 8:53 AM
  • Access use as a database store is not being extended.  For example, the x64 version of Excel greatly expanded the size of an Excel spreadsheet.  The x64 version of Access is still limited to 2GB.

    Microsoft appears to be turning Access into just a front end for its server based products.  (Yes I know that it has been used for that for years.)  There appears to be less and less support for standalone applications.


    http://www.saberman.com

    Thursday, February 07, 2013 10:49 AM
    • There are many bugs that have been residing in Access for years.
    • There are problems with various versions of Access on the same machine.
    • New versions of Access bring incompatibilities with previous versions. Some parts of old code don't work in new versions od Access.
    • Poor SQL-editor.
    • Very simple PDW which doesn't care of referenced libraries, OCXs, etc.

    All of these (and more) are well known issues. There has been no progress for several years.

    And some more:

    I don't want to flame but that's the way it is. It's my point of view.


    Vladimir Cvajniga


    Thursday, February 07, 2013 3:18 PM
  • @Saberman.

    Sure,

    I most respect your request for increasing file size.

    However, you can confortable fit 5 or even 10 million typical customer records in an Access data store now. The % of users that exceed these kinds of limits is rather rare.

    Adding table triggers and store procedures to the file based data engine certainly suggests a nice upgrade for that data store system, does it not?

    When is the last time we see so many features added to the data engine in the last 20 years? I see many posts saying that Access is not serious because it lacks store procedures and table triggers. Now access has these features and people cannot criticize Access for lack of table triggers and store procedures.

    Adding features to the data store system as opposed to increasing the size of the data store is likely more valuable to most users.

    Adding x64 bit support to the ACE engine was most important. The future world is x64 bits. And I also prefer adding "big boys" server type features such as table triggers.

    And increasing file size would further break compatibility with previous versions. We needed x64, but at the same time those files need to be consumed by the x32 bit version that people are running.

    I have been using Access for about 15 years. In that time I never have come close to reaching file size limits.

    I would say 9 out of 10 times most users would choose NEW features as opposed to increased file size. And that is exactly what occurred in 2010.

    Now of course, if you are one of the few that hits the 2 gig limit, then I certainly agree that those people are in a real bind. No doubt that small group would love larger file ability.

    However, there tends to be workarounds such a splitting, and then even using more than one back end. These are less than ideal solutions, but they are possible choices until such time one adopts a server based system.

    I think the reason why the file size not increased is because looking at typical databases, and even large ones, the 2 gig limit is sufficient for most users.

    I think just extending the file size to say 4 gigs likely would do more harm than good.  Users would become even more carless about planning and simple maintains like compact + repair would be even more abused.  Users would simply now run witout a C+R until they hit 4 gigs. And one can hit that limit with SMALL data sizes. They would just run untill they hit 4 gigs  and then wonder what is wrong? Often the simple solution is to compact + repair (C+R).

    If I had a choice between larger file size, and say adding data store options to recycle wasted space during database use? I would choose the recycling option over the "simple" approach of just increasing file size.

    So I think other features are more valuable than just an out of the blue file size increase. And I am hard pressed to think how features like table triggers and store procedures is not a enhancement to stand alone applications? So I see more featuers to the data store system in 2010 then in a very long time compared to previous versions.

    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada


    Thursday, February 07, 2013 4:51 PM
  • @Albert,

    I have been using Access since the 1.0 Beta -- a little over twenty years -- and I have hit the 2GB limit more times than I care to remember.  With the addition of attachments to the accdb format databases are likely to be bigger and bigger.  This is not a matter of needing to compact -- this is data exceeding the 2GB limit.  Yes you can split the back end but now you major bookkeeping issues.

    It should also be noted that the larger Excel x64 files are not backward compatible with previous versions.  Actually, if you use the new data types or the new features an Access 2010 database is not backward compatible with previous versions.  Actually, even if you don’t there are compatibility problems but that is for another discussion.

    I am not sure I understand what you mean by the advantage of triggers and stored procedures.
    This link: http://blogs.office.com/b/microsoft-access/archive/2009/08/13/access-2010-data-macros-similar-to-triggers.aspx
    says:
    " Data macros allow developers to attach logic to record/table events (similar to SQL triggers). "
    It also says:
    "VBA Support. You cannot call VBA from a data macro—this would not support the goal of portability to other platforms. "

    Again, it is part of Microsoft's push to server side systems.

    I have never (well almost never) found a use for macros -- VBA is much cleaner -- and always thought they were there for end users.  The only advantage I can see of the triggers is when users are allowed to directly change data in a table -- but that is not enough to save that type of system.  Changes made through a form with bound controls have the same events available.  Changes made under program control can be validated before an attempt is made to change the data in a table. 

    I do see the advantage of triggers in server side databases that are likely to be updated from many different applications and something has to compensate for, shall we say, illogical updates coming from some of the applications.  It is extremely rare to see Access applications with completely separate front end applications.


    http://www.saberman.com

    Thursday, February 07, 2013 7:44 PM
  • @ Saberman,

    You know, that is most fair. I do graciously accept this request comes up quite often. So I in no way want to throw cold water your point here. I WELL accept that a good case can be made for a larger file size. However, as noted, I do think when file sizes start reaching that size, alternates do exist.

    It would be rather un-fair to me to try and say this file limit size is a non-issue – it is not and those here make great points about file size limits. And given your long time experience, then you have much know-how and experience to make a great case that this file size limit is an issue for many.

    >even if you don’t there are compatibility problems but that is for another discussion.

    Sure, I much agree again. However to be fair, I was more pointing out that the x64 bit edition did not include new database file format "just" for x64. And while new features prevent backwards compatibility, file size without new features would just make this problem worse.

    So this changes little about the point of breaking compatibility. The problem here is even many non-Access applications could write to a database file and then that file would not be useable in previous versions when that file size is exceeded. So other applications (non Access) using the data engine could thus break compatibility. It just more issues dispite current issues that exist.

    >It also says:
     "VBA Support. You cannot call VBA from a data macro—this would not support the goal of portability to other platforms. "

    Ok, but I don't really think this means some server side push, does it?.  And you can call VBA from triggers anyway.

    >I do see the advantage of triggers in server side databases that are likely to be updated from many different applications

    Well, that is kind of my point. Access has a LONG history of other systems from VB6, VB.net, and FoxPro, c++ etc ALL OFTEN use update Access databases (jet). To introduce a VBA dependency makes little sense given this history and tradition of Access.

    And what database system have you ever used that allows the database to call client side code? From Oracle, to MySQL or even SQL server, they ALL HAVE their own special dialect of coding. T-SQL not a standard anymore then Oracle's PL/SQL. So how is this any different than every other vendor of store procedures code systems?

    Access is not different here either – none of these systems choose or used some existing system of writing code. So again, not using VBA, or having to use t-sql is a choice we are all faced when writing table code in most systems.

    And in fact you can call VBA code from Access table triggers.

    However, if you do this, then you need Access loaded (you need the expression service). And this would mean FoxPro, VB6 or anything else that opens that database will fail.

    So the Access data engine was often used for many applications (non Access). Why should all those applications now require VBA to be installed and loaded?

    And perhaps that documentation about triggers should be amended.  In the context of the database engine, they are correct you cannot use VBA and you are not writing trigger code in VBA. However, if you have VBA loaded such as when using Access then you can most certainly call VBA code from a table trigger.   Just use setvar with a public VBA function (so this allows passing + return of values from VBA)

    I think this VBA issue is more of practical design issue. Remember, if you use triggers and store procedures in the Access database, then you can open that database with a vbscript, VB6, FoxPro vb.net, and in ALL cases the table code and triggers will run (has to run).  So this design is a basic requirement of the database engine and not really a server side push or issue.

    And I don't think anyone going to make the case that VBA was designed for a database engine level coding system anyway (msgbox anyone?).

    If Access REQUIRED a server for the table triggers to run, then I would more accept that this being server side feature. Those triggers run without VBA, run without Access, and they run without a server. The basic design and requirement is table triggers have to run in standalone file mode without external dependencies.

    > It is extremely rare to see Access applications with completely separate front end applications.

    Well, actually, I think access databases are near as popular as dBase and other long lived formats in this industry. In fact I stated, Simply Accounting, and a ton of systems I seen have used JET for their database store over the years. I don't see ACE as being an Access only database engine now, and it certainly never was in the past.

    Introducing a VBA library dependences to JET at the table level would simply cause more problems than it ever could solve.

    IN closing:

    You make a fair case in terms of file size. And I think often I been hard on your case. In fact Saberman, please accept my apology in public. While this apology is buried in this long post, I think I not been the best ambassador for your cases in the past . I shall work hard to change this and I promise to support any case you make for the Access community.

    You are long time member and VALUED member of the Access community. You have tremendous experience and a lot to contribute here. As an community by working together and discussing these issues , we are all better off, and ultimate we make a better case for such issues.

    So in these cases you deserve and will get 100% of my support on these types.

    So, sure, I much accept that one can (and should) make a case for increased file size beyond the 2 gig file size.

    My personal view is I would prefer investments to go into other areas of the data engine such as improved ODBC error handling and reconnecting when ODBC fails for example. And I want project HURON to make it way into Access (sync to sql server).

    Best regards,

    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada

    Friday, February 08, 2013 5:19 AM
  • >Access & TFS: very poor performance & unstable.

    Hum, my setup is rather fast with TFS, and it has been very stable.

    Even when using Visual Source safe with Access - performance was just fine - but few used it. I think the "few people" is the real issue here. SSC been around for so many years in Access with so few using it - I like this feature but I also think it time to let it go due to lack of use and that money need be spent on other areas of Access - perhaps fixing some of those other issues you point out! People don't realize that resources are limited here. You pick to fix one thing, you going to lose in some other area.

    I mean, if you think SCC and TFS needs work, then how can one even being to address other issues? This is cost vs. return issue and as noted while I like SCC, I can't make any real commercial case for the return on continued investment for SCC in Access.

    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada

     

    Friday, February 08, 2013 5:27 AM
  • Ummm... MS thinking:

    • Today we add ADP. We'll remove ir tomorrow.
    • Today we add SCC support. We'll remove ir tomorrow.
    • Today we add something else. We'll remove ir tomorrow.
    • Etc...
    • Etc...
    • Today's syntax is TodaySyntax. Tomorrow's syntax for the same thing will be TomorrowSyntax.

    No one knows what happens on the day after tomorrow. No developer is willing to risk anymore. Access is not a tool for a real developer.

    BTW, my Access just hung up when I tried to check out an object (TFS). Will need to spend some time on a form I was working before to make the changes again. This is not RAD.

    When talking about a project I mean a project like this:

    Tables.Count = 386 
    Forms.Count = 360 
    Reports.Count = 336 
    Queries.Count = 1588 
    Modules.Count = 77 

    Vladimir Cvajniga


    Friday, February 08, 2013 6:18 AM
  • Well, who is using dBase right now? Who is using Apache 1.1 now?  Who is using Delhi right now? (BTW, Access has outlasted them all).

    The first version of Firefox supported Mac OS X 10.1 Puma (introduced Sept. 2001), but version 1.5 (May 2003) dropped support for it.

    Flash also does now not support Leopard.

    I mean, what version of Delphi are you using right now?

    Please explain to everyone here what platform you adopted in that features and support for things never changes?

    I mean, really, let's not start throwing out your own dirty garbage here.

    ADP in Access lasted longer then Turbo Pascal or most Delphi products did in the marketplace. And if you want, you can deploy the Access runtime for the next 10 years if you want to run ADP's (how is a 22 year run of using software too short for you? Can you respond with a well thought out intellection response why you feel 22 years of running an ADP application is not long enough for you?

    I suppose, perhaps you looking for support for DOS 3.1 and want to go back to use an old version of FoxPro for DOS. In fact, it is ironic that the that 20+ year old version of FoxPro actually DOES install on a brand new windows 7 or 8 box. In terms of compatibility and longevity in the marketplace, Microsoft products have among by far the best track record.

    In the SAME time frame Apple products have forced 2 or 3 time 100% throwing out of pervious software (that bought and paid for software simply would not run on the next version of Apple's system).

    While I can run that old version of DOS FoxPro on a new machine, I cannot run ANY of my older software from Apple from that time frame on a new computer.

    So if you trying to make an intellectual case for longer term compatibility and preservation of your software investment, Microsoft has the best track record by a country mile.

    The basic issue here is needs and demands of the market place changes.

    So, please do share what developer tool you are adopting that does not change its support over time? (since I not aware of one such system).  And of course since we are comparing to Access, then you ALSO will have to name a product with a longer life span you are using, and recommend to everyone here. Can you do that with a straight face?

    I guess at the end of the day, I don't want a special or unusual criteria applied to Access, but not  other products you use for development.

    And in fact, such criteria then should apply to your company and their products and how they support customers.

    So, please, do make some good points here. However, I am not interested in a discussion where you are simply unzipping your pants and dumping on everyone in this forum. Ranting like a 12 year old boy who dropped his ice cream on the ground and who is now crying like a 5 year old boy not going to help here.

    Be fair. So now please share with us here what developer tool are you are talking about with a longer life span then Access.  And what tool(s) are you using that have not changed what they support over time? And what tool do you feel has been in use longer then Access that has a better track record in the marketplace in terms of long time support and compatibility?

    In other words, you need to show me a tool you are using that been in use longer then Access (or as long) that has a better track record for support. I doubt you can do that, but I am most graciously open to such suggestions to something with a similar feature set of Access that has a better track record then Access in terms of longevity, and support.

     I am personally hard pressed to come up with something that had been around longer then Access. In fact the only personal examples I have are in regards to a few mainframe systems, but then again that not windows PC based software.

    So, put you money where your mouth is - what tool you talking about with a longer life span then Access are you using that you feel is so much better?

    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada

    Friday, February 08, 2013 6:42 PM
  • Microsoft general has a good record of support -- but not necessarily with Access or VB or VBA.

    Windows 7 SP1 broke ADO because Microsoft broke one of its primary rule about not changing the definition of an interface.  See:
    http://social.msdn.microsoft.com/Forums/en-US/windowsgeneraldevelopmentissues/thread/3a4ce946-effa-4f77-98a6-34f11c6b5a13
    warning -- it may take a while to load.  Please note that it is not even the entire thread as there is piece before it and another thread started after it when it got too large to load in a reasonable time.

    This caused many vendors that distributed products using ADO have extreme problems with their customers as applications compiled on Windows 7 with SP1 would not run on Windows 7 RTM or any lower level operarting system.  It also caused major problems in shops that had applications using ADO compiled on Windows 7 RTM after they applied SP1.

    Instead of releasing a hotfix to reverse the changes they tried to come up with all sorts of workarounds none of which actually solved the problem of incompatibility.  The suggestion I found the weirdest was to move to Windows 8 -- then in beta -- to compile applications as they said that had the fix in it. 

    They finally released the fix for Windows 7 over a year after the problem was reported in the released version of SP1.

    If you search the thread for Beta you will find that the problem was reported to Microsoft during the SP1 beta but it was ignored.  So the lead time for the fix was well over a year.

    As to the length of product life, for PC products, VB had a longer run than Access has had to date although Microsoft eventually dropped support for the developement environment and, with the relase of VBA 7, it also dropped support for VB6.  Actually, Windows 7 still supports the VB6 runtime engine but seems to be missing many of the COM objects VB6 developers used.

    However, if you look at mainframe products, IBM's DB2 has been around for over 30 years and IBM's IMS for over 40 years.

    Apple is in the hardware business.  Thus its new hardware has to make the older ones obsolete.  The Windows 8 Phone OS will not be available for Windows 7 Phones.

    Microsoft, until quite recently, was in the software business.  Thus, new releases have to make older ones obsolete.  Access has gone through major revisions which dropped backward compatibility.  Microsoft's end of life policy drops mainstreams support two years after the successor  (N+1) product is released.  Mainstream support for Office 2007 will end October 2012.  That means that bugs still in Access 2007 are unlikely to get fixed.  Office 2010 will lose mainstream support in June 2015.

    So to say Microsoft has supported Access for 20 years is symantically correct but not quite accurate.  Microsoft has supported a series of products all called Access for over 20 years.

    Please don't get me wrong.  I think Microsoft has done a fantastic job of providing opportunities for developers (like me) over the years.  In dominating the industry it has provided a level of horizontal standardization that has lead to huge productivity gains in many industries.  But please recognize it for what it is -- a profit driven company.

    By the way, how many existing applications can you run on Windows 8 RT?


    http://www.saberman.com


    • Edited by saberman Friday, February 08, 2013 8:52 PM
    Friday, February 08, 2013 8:49 PM
  • I am sorry but I had one more comment to make about Microsoft support for Acces -- actually it is about Microsoft support for VBA.
    VBA is a wonderful tool for prototyping components.  One could easily build an add-in prototype and then use Visual Basic to turn it into a COM object that could be used as an add-in.  That is until Microsoft dropped support for the VB development enviromnet.

    When Microsoft killed VB6 it destroyed that ability.  One had to prototype in VBA and then convert it to VB.Net (which was not easy as it was a thin wrapper around C#).

    This problem will not be resolved until Microsoft replaces VBA with VB.Net (which will eventually happen).  Until then developers are, how shall I put it in words that belong in a forum, up the creek without a paddle.


    http://www.saberman.com

    Sunday, February 10, 2013 6:33 AM
  • RIP VB6. We really do miss you.

    Look forward to eventually getting .Net in Access. Why so long a wait? If AutoCAD can do it then why can't MS?

    I'd dearly love to setup SCC in A2010 but can't find a straight forward explanation of the process. Lots of info presented here but I'm not finding a clear path. At least not for A2010. The best I can find is on 2007 and that doesn't quite fit.

    Anyone point at a good resource that is A2010 specific?


    Kent

    Monday, February 11, 2013 4:32 AM
  • >RIP VB6. We really do miss you.

    One of the nice things about VBA/VB6 was that you could develop inside of Access and then port the code to VB6 to create an add-on for any of the Office products.

    >Look forward to eventually getting .Net in Access.

    Be carefull what you wish for.  It will come but it will be a wrenching experience.  In VB6/VBA you could do just about anything you could do in C.  With VB.Net it is not so easy.  The conversion from VBA to VB.Net will be even worse than the conversion from VB6 to VB.Net.


    http://www.saberman.com

    Monday, February 11, 2013 5:19 AM
  • I've installed AccessDeveloperExtensions.exe (for A2010) but I'm not seeing it on the Ribbon. Should there be a new tab?

    Kent

    Monday, February 11, 2013 5:40 AM
  • You need to install MSSCCI provider, too.

    As to SCC, I'm not sure if there's any diffenrence between A2007 and A2010. I think there's no difference.


    Vladimir Cvajniga


    Monday, February 11, 2013 2:07 PM
  • Albert, I'm not talking about DOS, Delphi, etc. I'm talking about Microsoft Access.

    I'm affraid data macros will disappear one day... as many others did. MS Access developers don't care about backward compatibilty. That's why I say that MS Access has become a toy. Unfortunatelly...


    Vladimir Cvajniga


    Monday, February 11, 2013 2:29 PM
  • Trying to install MSSCCI raises the message

    Microsoft Visual Studion Team Explorer or its tools are not installed or registered

    So can we start from the beginning. What do I need.

    Do I need to Buy Visual Studio? or will Express allow me to use Team Explorer? Do I really need Team Explorer?

    Can anyone explain the whole process?


    Kent


    • Edited by KentGorrell Monday, February 11, 2013 11:01 PM
    Monday, February 11, 2013 10:57 PM
  • OK, the next step is to download and install Microsoft Visual Studio Team Explorer. :-)

    Free version should be available somewhere @ microsoft.com. Be sure you'll get an appropriate version according to applications you have in your system.

    Also see System Requirements on the web page where you  downloaded MSSCCI Provider from.


    Vladimir Cvajniga





    Tuesday, February 12, 2013 7:12 AM
  • We don't have Access 2013. We must stay with A2007 since we need SCC support.

    Vladimir Cvajniga

    Wednesday, February 13, 2013 4:37 PM
  • I'm affraid data macros will disappear one day... as many others did. MS Access developers don't care about backward compatibilty. That's why I say that MS Access has become a toy. Unfortunatelly...

    Actually, data macros will probably survive.  It is VBA that will eventually be killed.


    http://www.saberman.com

    Monday, February 25, 2013 8:40 AM
  • LOL, the same nonsens start again. If VBA will be killed then Access (the way we know it), is dead, too. They already tried to get rid of VBA in Office for Macs and it's back again. And they tried to replace VBA in Word, Excel, ... by .NET and code behind the documents. Didn't succeed, either.

    But who knows, when I see how MS developed in the past years they even risk to killing Access.

    Henry

    Monday, February 25, 2013 8:52 AM