I want to use the source code repository for the MS Access Project. The code Repository requirement is more for version control of the application than multiple users accessing it.
can anyone suggest a code repository to be used for this particular requirement
I use this VCS system for Access: https://github.com/NCPN/Access_VCS
Related
We're running Microsoft Dynamics CRM 4.0, and setting up custom JavaScript event handlers on several of our forms.
I'd like this JavaScript code to be kept under revision control, but I'm not aware of any way of deploying changes to these scripts, other than manually editing (or copy/pasting) the code in the Dynamics CRM entity customisation forms - which means it would be all too easy for someone to make changes to the running system and 'forget' to copy/paste their changes into the revision-controlled version.
I'm wondering if we can use something like a trigger or a FileSystemWatcher component to catch changes to these files and make sure they're stored in revision control - but I have no idea where to find the actual raw scripts. Are they stored somewhere in the MSCRM_CONFIG or MyCompany_MSCRM databases? Or on disk somewhere on the CRM server itself?
Thanks!
It's basically included in the FormXML which is the definition of all forms in your environment. It is stored as part of the organizationui.
See also http://social.microsoft.com/Forums/en-US/aaa6f404-81eb-467d-b9bb-3d29108ec92b/where-does-crm-40-javascript-code-get-stored-in-database
The JavaScript is stored inside the database, I can't find the exact table for CRM 4.0 (here an article about CRM 2011 location just for your information http://kellyhoang.blogspot.com/2012/01/crm-2011-customization-decript-default.html)
There is also a tool for extracting the JavaScript from a CRM 4.0 instance, you can find it here:
http://blogs.infinite-x.net/2011/09/30/export-javascript-crm-4-0-updated/
(you can decompile it to look how it works, or ask the author directly)
I have an Access database for which I have created a 2010 runtime version.
I sent over to a partner in India where their predominant machines only have Access 2007 installed.
They have installed Access 2010 Runtime to these machines, but make the following claims:
No access to Nav Pane - to see/open tables
No menu ribbon
No table/datasheet right-click functions (sort, find, etc.), except as I have implemented under buttons on the form.
I see all these functions when I run on a 2010 VM. I don;t have a 2007-only machine to validate or debug their claims.
Does this result sound odd?
I suppose I could work around some of these:
Populate the current list of tables in a listbox on the form
Create a custom menu with the necessary functions
Not too sure about the table/datasheet right click functions
Not freaking out just yet, but getting close... I cannot re-build this thing DOWN to 2007.
Any advice anyone?
Does this result sound odd?
Not really. It sounds like you were opening the .accde file using the full Access 2010 application while the other team was opening it using the Access 2010 Runtime.
The Access 2010 Runtime environment does not include things like the standard ribbons, navigation pane, etc.. If the developer intends to deploy the Access application under the Runtime then the expectation is that they will provide custom ribbons and navigation tools as required for that particular application.
Note that this is true whether the Access application is distributed as an .accdb file or an .accde file. An .accde file is simply an .accdb file with the VBA source code removed and the users being prevented from opening objects like Forms and Reports in Design View. Those changes help "lock down" an application when opened in the full Access application, but they don't make any difference to the behaviour when opened in the Runtime environment (because the users can't perform those operations in the Runtime environment anyway).
Developers can test the "Runtime" behaviour of their applications by opening them in "Runtime mode" in the full Access application. This can be accomplished in either of the following ways:
Create a shortcut that invokes MSACCESS.EXE with the /runtime switch and passes the name of the .accdb file to open.
Temporarily rename the .accdb file to .accdr and open it. .accdr files automatically open in Runtime mode.
We are working at getting our versioning control product to automatically push our SSRS reports to the Test (and then production) SSRS environment. When we promote changes from our development to our QA directory in the versioning control application (Surround SCM), we would like for it to also publish the report to SSRS. (This is the workflow we use for our web applications, and if possible I would like to be consistent).
Now, the directories in SSRS are not "real" directories, at least not as far as I can tell. But is there any way to map a network drive to one of these report directories? And if we do this, and Surround SCM can write changes to that directory, would they then be saved to SSRS?
Sorry in advance if this is a really esoteric question, or if I am missing a really obvious way to do this.
No, you can't directly map SSRS folders to a Windows filesystem. I haven't found a way to make what you describe as easy as I think it should be.
The easiest way to automate the deployment of reports uses of the rs.exe utility. This can execute scripts to deploy or update reports.
Alternatively, you could use the SSRS web services to deploy the reports from .NET code.
Using Script Task, I have written a code to create a folder and create a MS Word document inside the newly created folder. It is working on the local machine but it is not working on the server where the package is deployed to. The folder is created successfully, but the Word document file is not created. For Word document creation, I had to refer another DLL where I had included an additional namespace Microsoft.Office.Interop.Word. Is there anything else to do before deployment ?
Based upon rfonn's comments, your choices are as follows:
Install Word 2007 on the server.
Re-do your package on a dev box with Word 2003 installed and deploy to your server.
Use some other tool to generate the Word Document.
SSIS is generally used for movement of data, so while it is possible to do what you are doing, it is likely not the best tool for the job. If you are capable of writing code in a script task to do what you want in SSIS, it is possible to write a program (VB or C# or any other tool you choose) to do the same thing without SSIS being wrapped around it. My money is on option #3 being your best choice.
I guess you missed installing the Office PIA.
After installing the relevent PIA according to your Office version, add a reference to microsoft.office.interop.word (.NET) file in your project (ssis script in VS).
As the title says, I would like to use Vault for source control of an MS Access application that contains forms, queries and modules with vb code. I want to avoid the tedious process of exporting and importing modules to and from text files for the purpose of diffing with previous code.
Thanks.
Access 2003 does work with Visual SourceSafe 6.0.
I have to assume since access does have support for SCC, then perhaps it is a standard interface? I don’t believe SCC for ms-access will work with SourceGear.
You can find info on using VSS 6 with ms-access here:
http://support.microsoft.com/kb/837136/en-us
I used SCC with ms-access. You can even check-in/check out forms or even queries. So, it does allow more then one developer to work on the application at the same time.
Keep in mind the above SCC for ms-access works by using the un-documented
Saveastext
And the reverse is:
LoadFromText
Type the above two commands in the access debug window, it will give you inteli-sense as to what the options + parameters are.
With the above information you certainly could import + export bits and pieces in and out of ms-access into Source Gear.
So it is a bit of a long shot to get SCC feature of ms-access working with Soruce Gear, but you could cobble together something that pulls objects in and out of Source Gear by using the above two commands.
The only thing I can add to Albert Kallal's answer is that I actually did use MS Access with two different source control providers - with MS Visual SourceSafe and with SourceGear's SourceOffSite.
There were some occassional problems when our team was using SourceOffSite - like sudden failures of MS Access during some source control operations - but all in all it worked. (Perhaps those problems were caused by the fact that we sometimes "mixed" those two source control providers - i.e. one developer was using VSS and another was using SOS. So I can't really blame those problems on MS Access itself.)
Now, I never used Vault. But, since SourceOffsite and Vault come from the same vendor, I think there is a very good chance that (a) SourceGear offers an MSSCCI provider for Vault and (b) MS Access can be used with Vault successfully.
Hope this helps.
I haven't tried earlier versions, but I can confirm that SourceGear Vault 5.0.4 can be used with Microsoft Access 2003 (with the Access 2003 Add-in: Source Code Control installed).
For this to work, you need to enable a option in Vault Client called "Make Vault your default SCC provider".