We have an application to track work orders (hundreds of thousands) built on an Oracle database. Data entry is cumbersome and report features non-existent. IT is inflexible. We do not get support from that end. Accordingly, users have created Excel "tools" to run queries and make sense of data using ADO or ODBC connections.
What we also need is a way to record comments on specific work order (WO) records and have those comments travel with those records somehow. There are multiple users using their own spreadsheets, all querying the same database.
I'm envisioning a junction-table approach, perhaps using Access, where some VBA could take a users comment from the row in the worksheet, capture the WO number, user id, date, and comment text and store it in an Access table. Those fields could then be retrieved by some more code. This would allow any user to see all comments by any other user related to a specific WO.
I'd greatly appreciate feedback ... on the practicality, preferable constructive, but brutally honest is ok too.
Much thanks,
Kevin
Apart from this being a horrible mess you could:
use SQL Server instead of access - you can get a free copy that will probably cater for your needs. Access will also work, but it is bodge. SQL server is more professional!
I would avoid doing data entry in excel. You could build a front end (possibly in Access with SQL Server backend) that allows data entry. You could add pretty simple code to all your workbooks, which will probably reference code that will be in an excel addin. The addin has code to simply open an access database, open a form and find the WO that the user was viewing in excel.
2a. Or you could use an excel addin with a data entry form, to do data entry, but beware managing the locking, refreshing and update of displayed data.
Creating excel addins is easy, (re-)distributing them is easy, access (or whatever front end you use) is designed to do record management (ie lock and update or lock and cancel or just view) etc.... Plus you want to avoid addinghte same or similar code to all your workbooks.
Each users workbook would have very simple code. Just to tell the addin what WO you want to operate on.
Do you have sharepoint? If so Access 2013 can deliver forms as webpages - very easily, so you might not even have to manage a front end access file.
Happier now?
For those that may stumble on this post, what we ended up doing was use VBA to store comments in a separate SQL database. Users double click the cell with the WO number to get an input form prompting for comments with options to add new, append or remove existing. Entries are passed to the SQL db and also to columns in the worksheet so users can see all the entries. Time stamp/Network ID provides when/who provided comment. Existing comments are fetched when users re-open file. Works great.
Related
I have a tool that uses an external data connection to keep a dashboard updated from single CSV which contains a data log. I don't want anyone touching the log itself and fiddling with it, so I have put together a small dashboard that is fed from the data displayed by the connection.
I have the connection set to update on open and every 10 minutes in the background, but it does not do this. Instead, I need to manually press refresh, whereupon I get the following message:
'Microsoft Office has ifentified a potential security concern' message box example
I absolutely trust the source in question, but do not want my user to have to click refresh every now and then to make sure their data is up to date.
How can I make this connection 'trusted' and have this persist through sessions?
(Apologies if I have missed anything or this isn't the right way to ask this question. I'm new! :) )
Moved the tool and it's peripherals to a (trusted) shared drive, and no problems.
I am relatively new to VBA and I need a solution to a problem I have.
Currently I have two excel documents - one which is a form where the user enters data and this is then sent to a second document which acts as a database for this information. My issue is that when people are looking in the database data cannot be sent to the second document because it is open and there are overwrite errors.
It is my intention to have the databases location hidden away within a network drive so it cannot be found meaning the only way to access I is through a button on the first document.
Is there a way that when the open button is pressed to access the database that a copy of the document is opened instead of the actual document itself so data can still be sent?
So, you have a few options here:
a) Use an actual database. Not so much to solve this specific problem (that too) but also because making a "database" in excel is usually a terrible idea in the long run. But I know that is not always possible, and it's overkill in many situations so...
b) Have that "database" workbook set as "Shared Workbook". Shared Workbooks come with their own host of issues (namely, can't edit certain aspects like the VBA in them, conditional formatting, and others). But if it's strictly for reading and writing data, it can work. It also comes with its own version control, so that's good.
c) What you originally asked. It is quite simple really, as you said, you make a copy of the document, ideally in one of the user's local folders . You can do this using FSO (see VBA to copy a file from one directory to another)
The only issue with this last approach is that you need some way to track when the user has closed that temporary file, in order to delete it (if you absolutely don't want to leave any traces). Otherwise, you can just leave it, and overwrite that same file each time the user presses the "View Database" button.
I'm currently working on maintaining some old (new format .xlsx) excels with more than 60+ connections each that feed some various tables from a SqlServer.
I'm in search of some kind of toolkit, module, standalone script (or anything really) that let me bulk change the command text inside each connection properties.
The change should be not harder than changing part of the table name as the new table only contains the information that the table needs.
So far, the only thing that gets near what I need are those python modules but they don't appear to implement anything for handling connections.
Thank you in advance for any help you can provide.
I'm trying to wrap my head around it. I've checked other questions and nothing seems to be too similar.
The Office 2013 development centre contains extensive DAO examples and states it is one of the easiest ways to work with an Access file (does not require an Access window) but DAO is a deprecated technology. (https://msdn.microsoft.com/en-us/library/office/ff834801.aspx)
I'm trying to write an Excel Add-in (eventual end point) that will grade Access assignments in .accdb format.
I'm can't just use ADODB to perform SQL queries to extract data, unless SQL can also do the following:
check a specified report has a specified title
check that specified tables, queries, forms, and reports exist
check specific fields in a table exist
check that specific fields have been set as the Primary Key
I also need to check that certain values exist in a table, but those I can solve with SQL.
So should I be using DAO or stick with ADODB? Remember, I'm using Excel, not programming in Access VBA.
The simplest way to work with excel tables is to link them in Access either manually or via the TransferSpreadsheet function in VBA. If you use a generic naming standard for the file names and tab names in Excel, you will not have to relink, rather you can replace the Excel file and the Access link will read the new file unless the layout has changed.
Once linked you can use the query-by-example tool to write your queries which also can be written into code (i.e. either embedded in the VBA [old school and not a best practice] or saved in an Access table then looked up and assigned to a variable for use with the CurrentDb.Execute strSQL, dbFailOnError command.
I suggest manually linking the first go round so you can manually define the individual column types vs. letting Access mess it up.
If you cannot use generic names and have to pick the file via a browse dialog, you can get a file browse function via Google to allow you to programatically link the file. (or you can rename it to a generic name which works even better)
So DAO vs. ADODB is moot from an Access perspective. I supported 50 databases with 70,000+ lines of code and dozens of Excel source files the past 4 years and never had to ponder the question.
Microsoft originally deprecated DAO in favor of ADO, but recently renamed DAO to Microsoft Access Engine (ACE) and is now pushing it as the preferred data access technology for Automation-supported environments (VBA, WSH etc.)
In general, in your scenario I don't think it makes much of a difference which one you use. I suggest you read through this.
I don't think it's possible to read table/query/field information via SQL. However, this can be done either with the DAO.TableDefs and DAO.QueryDefs collection, or the ADO.OpenSchema method.
RE: forms/reports - I don't know if it's possible to read form/report information via DAO or ADO even without SQL, as it is actually part of the UI objects, and not the data; unless we're talking about reading/parsing the system tables. You may have to open the database in a hidden Access instance and read the forms/reports that way.
I need to migrate Work Items from one TFS server to another TFS server. I tried migrating them using the TFSMigration tool available in CodePlex.
The problem I am encountering is the schema for the work item on the source TFS is different from the schema of the work item type on destination. I don't want the destination TFS server schema for the work item to be modified. The change in schema is one new column only, but still don't want to take that change.
In one blog it was said that we can do that using Excel but not much details were available. I am not sure we can even use Excel to migrate the entire history related to Excel.
Have a look at the TFS Integration Tools on VS gallery. This supports custom field mappings as part of a migration, documentation here (direct download).
I did this a while back and, not finding an appropriate tool, resorted to copying the title and description etc across manually, as we only had a few active work items at the time, so it only took about an hour.
however, if I need to do it again, I'll use the TFS API to read fields of interest and write them to the new database. that way any schema differences don't matter, and the process is automated but under your control. Search for studying work items with the TFS API for details - it's really very easy.
Of course with both of these approaches (and all the migration tools AFAIK) you will only get a snapshot of the data - all history will be lost (or at best you can query using AsOf to get historical data, but all the entries you make will be timestamped at the moment you write them, not with the historical time that the event originally occurred.)
You can use the Excel editor to edit the source query All Items "Open Query in Microsoft Excel". Then open the destination query All Items "Open Query in Microsoft Excel". Copy and paste the contents from one excel window to the other. Certain fields like attachments will not transfer.