My company hired an outside firm to build a complex program for them through Microsoft Access. The program is designed to link with a second access database, run a series of linear equations in the background, and spit out a few reports. As a user, I interface with a simple GUI in the Access file to 1) tell it which database to link with, 2) manipulate some data, and 3) run reports.
If possible, I would like to see the back end of this program to see the programming logic and to identify how it creates the reports. I am familiar with the basics and the methodologies of Microsoft Access, but don't know much about the dedicated functions of the application.
Thank you for your advice!
The Access / GUI file is actually the front-end, whilst the database you select in the GUI will be the particular back-end you're dealing with. The coding is most likely to be in the front-end as VBA (or as a series of queries, macros & reports).
So, try holding shift when you double-click the Access file, which will try to load the GUI in "design" mode. As #June7 noted though, if its a locked-down / executable mde or accde this won't work, it'll need to be mdb or accdb. You'll also require a full version of MS Access, not just the free runtime installed on your machine.
If you manage to open in design mode, you should be able to see any tables, queries, forms, reports & VBA modules in the navigation pane on the left of the screen... unless of course, they've made them hidden objects. The can be unhidden if this is the case, though.
There may also be password-protection on some parts (which is easily crackable using info you'll find on Google).
Related
I have used a variety of WYSIWYG web builders before. I now have a new website that I would like to create that is a bit beyond my skill set. The website will need to have some kind of IDX plugin or interface for real estate listings. There are a ton of different options out there for this. However mine will also - ideally - display microsoft access based forms and reports on specific pages. I'll need to design how the forms & reports are displayed. A plugin would be fine. My understanding is that Access can interface with the web through asp.net as long as the db is hosted in the cloud. I also have a mail chimp account that should be connected with the same site. I would like to know if anyone with more technical knowledge than myself can make any recommendations as to how to pull these pieces together and if I should ask any specific hosting or servicing questions as I do my research. Many thanks!
Well, a c# program (non web) can connect to sql server.
A c# program or a foxPro, or even a vb program can connect to MS-access.
And a web site can connect to sql server, or MS-access.
However, in ALL of these cases, we talking about a program interface that allows one to read the tables as a database.
Access has two parts.
The database part. This part can be consumed by c++, asp.net (web site), FoxPro, V6, vb.net and just about ANY development set of tools that supports the MS-Access ODBC drivers.
However, you can't call MS-Access "just" a database. MS-Access includes two parts:
The database part (this is the database engine). This ONLY allows you to open the database table(s) and work with the data. So VB6, or FoxPro, or vb.net can thus read + use MS-Access as the database.
However, this has ZERO to do with code, queries, forms, and reports written in MS-Access.
So, when someone decides to use SQL server + a web site?
Then you have use of the tables and can submit sql to the database engine. That database engine might be Oracle, or MySQL, or SQL server or MS-Access data engine (ACE/JET). However in all of these cases, you not using VBA code from MS-Access nor are you using reports, nor are you using forms.
So, Access ALSO include a IDE and development part. That development part allows you to build a application. But a application has ZERO much to do with a database.
So, while you can use the data from MS-Access and connect to the tables, the forms, the code, the reports have ZERO to do with web devleopment, and thus the forms and code in that Access database can no more be used on the web then can some code written using Turbo-Pascal, FoxPro, VB6 or any other desktop development system. VB6 has ZERO ZERO to do with web development. Foxpro has ZERO ZERO to do with web development. And Access has ZERO ZERO to do with web development.
So you can "use" the data from FoxPro or say the data from MS-Access in a web site, but ZERO OF THE code in such desktop systems can no more be used for the web.
You can no more take desktop code for windows and run it on a Apple II, a iPad, a Android phone, or run such code in a web site. They are about as different between a bicycle and a helicopter.
So the ONLY part you can use from MS-Access applications written for the desktop part? Answer zero, none, nada!
The only part that you can use from a MS-Access database say in FoxPro? Only the data part - not the code and UI parts.
The only part you can use from a MS-Access database say in VB6? Only the data part - not the code and UI parts.
The only part you can use from a MS-Access database say in VB.NET? Only the data part - not the code and UI parts from MS-Access.
The only part you can use from a MS-Access database say in c++? Only the data part - not the code and UI parts from MS-Access.
The only part you can use from a MS-Access database say in a asp.net web site? Only the data part - not the code and UI parts from MS-Access.
So you are confusing the application part (code, forms, reports) that belongs to a given application. If you going to use a whole new different development system? Then what system in the last 30 years, going all the way back to say software written in Turbo-pascal, c++, VB6, FoxPro or ANY system could you by some magic act use the code and parts from those DIFFERENT application systems in another new application you plan to write?
The answer is ZERO parts!!!
You can no more take code and forms written in say Pascal and expect that code to now run and be used in say VB6, or VB.net.
So, you are most free to move/take/grab/consume the data from MS-Access and use that in a web site. But the code, form, reports etc. written in MS-Access cannot be used for the web, no more then some forms and code you wrote in BASIC for your Apple II can be used on the web.
The only part you can move in a automated fashion from MS-Access applications is the data part - not the code part.
You can no more take BASIC code and forms from a c++ program and shove them into say an MS-Access application you plan to write.
So, you MUST distinguish between the data parts of a given application, and that of the UI and forms and code. In general, since the VERY first personal computer came out, this MOST basic and fundamental concept? Code for one application and system cannot be salvaged, used, nor converted in some automated fashion.
If you want to move code from c++ to MS-Access? You have to re-code and re-write that code.
And if you want to move code from MS-Access to c++? You have to re-code and re-write that code.
And if you want to move code, forms, logic, reports from MS-Access to some other new platform - say like some new set of web development tools? Once again, this a manual process, and it been that way since the very first computer came out!!!
so there are a gazillion web development platforms. More platforms exist then there are flavors of ICE cream. You have to go and find one you like, or one that suits your fancy, or what that maybe you took a few courses. However, not knowing your past experience, and ALSO that outright recommendations of software product X or product Y goes against the code of conduct on StackOverflow. And this is a good thing since then these boards would be swamped and over-run with people selling their wares and products here as opposed to a community that helps developers answer coding and development questions based on a particular tool or platform.
I have a website online with just HTML and I am not willing to use any other programming language apart from Javascript. All I need to do is connect my Microsoft Access database on my computer to a form hosted online so when information is submitted online it is updated on MS access the next time I open the file up. Is this possible and how can it be done?
Turns out, you can do this with zero code. If you use office 365, and publish an Access web forms.
Any information entered into the Access web form will automatic appear in your local database. The synchronizing of data from the web site and pulling down of the records to a local copy works automatic and without the need to write any code. In fact the sync starts automatic when you launch the client application. (it runs in disconnected mode). And any records you enter in the client application will also sync up and appear on the web site.
So, you can use Access and write zero code, and this two way sync feature is built in.
You need Access 2010, and either SharePoint 2010 (enterprise), or you can use office 365 and the $6 per month p1 plan which also does support Access web publishing.
However, I suspect issues of user logons and security may well be a greater issue here, and thus office 365 might not be correct from a user logon point of view. You can invite up to 50 users to that site for the basic $6 per month, but all users of the site will require a logon (which can be due to being invited to the site).
There are two videos of mine here showing this setup in action here:
http://www.youtube.com/playlist?list=PL27E956A1537FE1C5&feature=plcp
I think what you are trying to do is very impractical. You'll need to use Server Side Javascript to insert your data into a database, preferably SQL Server, and then you'll have to write some kind of code to sync the SQL Server Database to your Access database.
Alternately, you could setup your Access database so it connects to the same instance of SQL Server as your website using ODBC linked tables or ADO. I cannot really recommend this, especially if the data you have in your Access database is anything you wouldn't want to be public. Also, using MS Access to access a database across the WAN/Internet is really not recommended although it can certainly be done, as long as you aren't working with large amounts of data, large quantity of records, etc.
I am not willing to use any other programming language apart from Javascript.
And why aren't you willing to use something else? I don't think you're going to get anywhere if you don't open your mind to using the right tools for the right job.
Here's something that might help you get connected to SQL from Javascript:
How to connect to SQL Server database from JavaScript in the browser?
I am about to release an Access Database application where the UI is used exclusively to interact with the database tables.
Whilst I am interacting with the forms during run time, the Visual Basic Editor appears with a line of code highlighted in debug mode, even when no breakpoints exist and no run time error has occurred.
Has anyone else come across this issue?
I need to ensure that the editor does not appear (under normal operating conditions) while the user is interacting with the application.
Thanks.
Yes, I have had this problem too and it has driven me batty. The quick and dirty way of fixing it is to create blank database and import all of the objects from you old database into the new one.
Are your users working with an .accdb file? (or .mdb, depending on the Access version)
If yes, you should convert it into an .accde/.mde before giving it to your users.
Quote from the link:
Additionally, if the database design needs to be secured to prevent changes, Access databases can be locked/protected (and the source code compiled) by converting the database to a .MDE file. All changes to the VBA project (modules, forms, or reports) need to be made to the original MDB and then reconverted to MDE. In Access 2007 and Access 2010, the ACCDB database is converted to an ACCDE file. Some tools are available for unlocking and "decompiling", although certain elements including original VBA comments and formatting are normally irretrievable.
--> since .accde/.mde files are compiled, it's not possible to view the source code at all.
So the VBA editor can never appear accidentally like you experienced...be it because of a breakpoint, some Stops in the code or some strange breakpoint error like yours.
Is there a way to version the VBA modules inside an Access 2007 database, or am I just stuck with exporting the code and keeping it separate from the database and maintaining two different copies?
MS Access has a MSSCCI interface which you can connect to any source control system which has a MSSCCI interface. Many of them do. For example for SVN there is AgentSVN or VisualSVN.
Download and install the Access 2007 Developer Extensions, and choose the source code control from your installed SCC providers.
Source control in MS Access uses the Access SaveAsText/LoadFromText methods. All recent versions of Access use a VBA object to hold the VBA modules in, they aren't stored natively in the database anymore, so you can't just export the record holding each module as you used to be able to do.
There are mixed reports about using integrated source control in MS Access. Your milage may vary.
On a historical note, a multi-user, multi-process relational database is ideal for ensuring coherance in source code. According to some reports, the Office 2000 developers were unable to maintain project coherence when using the native database to store modules, and fixed it by using a locked single project object. Possibly missing the fact that Windows 2000 SMB server was corrupting data (fixed in Win2K SP1).
Based on the response so far, I conclude you can't have versioning.
I believe this is because an Access DB code-base is not viewed as a set of modules -- that is, not as interchangeable elements the way code is in many other settings. A truly modular approach increases the requirement for strict control because you must ensure coherence; thus, versioning.
Code in VBA is not handled as agile -- which of course is understandable historically. It's a huge watershed in development approach. So while you benefit from an agile mindset, you won't find it facilitated so well.
NOTE:
In case you're not aware, some key aspects of modular approach are met by separating the app into client and server documents (splitting your database).
We're looking for an easy way to display Access reports on the web. These reports have been written and viewed internally for years. They are not simple tables, but more complex charts and graphs. But, now people outside the organization need to see them. All of the data is in access. And, except for reporting everything else is working fine.
We have a web server that has permissions to see the Access database. However, the Access database server cannot be the webserver itself. So, the question is how do we view these reports on the web? This excellent solution, which I reference in case it helps others, (https://web.archive.org/web/20211020135306/https://www.4guysfromrolla.com/webtech/042600-1.shtml) does not apply, as it requires you to be on a company intranet . (Although, it may be possible to implement the solution outside of an intranet, so many security holes would be opened up that the developer leading this project would surely be fired.) If possible, we also do not want a solution that expects every client to install code, for example, the access runtime.
Is there a tool that can read the
access reports when requested? OR
Is there a tool that can upload the
data from the Access database on a
periodic basis and based on the last
retrieved data - it can display the
report that was written in access?
Other solutions ...
Thanks!
print the reports to pdf and then copy the pdf files to the webserver
Options:
output to PDF.
output to Access snapshot format and force users to use the snapshot viewer.
wait for Access 2010 with Sharepoint 2010 and Access Services and you're home free (as long as you can rewrite your reports to be full web reports, i.e., not VBA and only using the capabilities of web reports in A2010).
We deliver an Access app (and reports therefore) over a Terminal Server as a WebApp.