I would like to create 100 different reports - they all need to initially be saved to one location - then they need to be distributed to various locations on our network drive.
An Excel vba program is creating the files from an xlsm file saved on the network drive.
Which of the following approaches is more resiliant/defensive?
1.Save 100 files to C-Drive of machine running the code - then distribute to 100 different locations on the network drive.
2.Save 100 files to same network location where controlling xlsm file is located - then distribute to 100 different locations on the network drive.
Well... that depends. How good is your network? =;)-
When faced with this situation, I tend to write local and them move them after the fact. In my experience, this is more reliable and faster.(Assuming you're using a cut/paste action and not a copy/paste action. Copy/paste is terribly slow.)
Now, that said, I would actually prefer to just write directly to the network drive. It's less code, less bugs, less chance for things to go wrong... IF you have a reliable network.
Related
I am a video editor, and I have access to one of my repeat clients' servers, which is mounted as a network drive. The connection is too slow, so I have to copy over any footage I want to use. I like to keep it in an identical file structure, to make re-linking the footage on their end easy, but recreating it manually is extremely tedious and time-consuming, as is individually copying each file..
My question is, is there a way to take a list of select files and batch copy them to my own drive while keeping them in the same file structure?
Essentially, I want the file paths to look exactly the same except for the drive letter.
The machine I'm trying to access is an industrial PC that serves as the interface for some PLC-automated equipment. The computer creates a data record (an .mdb database) of the various machine settings so that they can be reviewed later if desired. I've created an application in Visual Basic 2010 to display and sort that information once it's been copied from the machine to someone's laptop.
What I'd like to do, though, is allow the user to access the database from their laptop over the network; each PC has a static IP address on the customer's LAN. Currently, we can use Teamviewer to transfer files, but I'd like to include that ability in my data viewing application. Without changing any settings on the industrial PC (i.e. leaving the network file sharing alone, and avoiding installing any sort of SQL server software), how can I access this information? The database files can get pretty large (40+ mb) so I'm trying to avoid any sort of FTP transfer, which would undoubtedly take forever.
The database is already set up on an ODBC connection (which is how the pc stores the PLC information in the database), and I suspect that this may be the key, but between my lack of any thorough understanding regarding networking and the internet's general distrust of ODBC (well earned, from what I've seen so far), I'm having a hard time finding any useful information.
If anyone could point me towards some useful tutorials, or give me a good place to start, I'd appreciate it.
I think you are out of luck. Think about it, if you could access the file, without sharing it, wouldn't that be a serious security problem?
What you can do: Use the always existing share \host\c$ to access the file. For that you'll need administrative privileges for the host.
But be aware: Even if this "works", it introduces problems:
It will be slow, because you are essentially copying 40MB over the wire over and over again
If you are not carefull, you might lock the *.mdb file while accessing it. Access Databases are not really meant to be accessed by multiple users/processes. That didn't prevented Microsoft to try to fake it. Todo so, a *.ldb (L as in Lock) file will be created, to signal other processes the file is locked.
Tldr: Don't do it.
Firstly apologies if this question seems like a wall of text, I can't think of a way to format it.
I have a machine with valuable data on(circa 1995), the machine is running unix (SCO OpenServer 6) with some sort of database stored on it.
The data is normally accessed via a software package of which the license has expired and the developers are no longer trading.
The software package connects to the machine via telnet to retrieve data and modify data (the telnet connection no longer functions due to the license being changed).
I can access the machine via an ODBC driver (SeaODBC.dll) over a network, this was how I was planning to extract the data but so far I have retrieved 300,000 rows in just over 24 hours, in total I estimate there will be around 50,000,000 rows total so at current speed it will take 6 months!
I need either a quicker way to extract the data from the machine via ODBC or a way to extract the entire DB locally on the machine to an external drive/network drive or other external source.
I've played around with the unix interface and the only large files I can find are in a massive matrix of single character folder (eg A\G\data.dat, A\H\Data.dat ect).
Does anyone know how to find out the installed DB systems on the machine? Hopefully it is a standard and I'll be able to find a way to export everything into a nicely formatted file.
Edit
Digging around the file system I have found a folder under root > L which contains lots of single lettered folders, each single lettered folder contains more single letter folders.
There are also files which are named after the table I need (eg "ooi.r") which have the following format:
<Id>
[]
l for ooi_lno, lc for ooi_lcno, s for ooi_invno, id for ooi_indate
require l="AB"
require ls="SO"
require id=25/04/1998
{<id>} is s
sort increasing Id
I do not recognize those kinds of filenames A\G\data.dat and so on (filenames with backslashes in them???) and it's likely to be a proprietary format so I wouldn't expect much from that avenue. You can try running file on these to see if they are in any recognized format just to see...
I would suggest improving the speed of data extraction over ODBC by virtualizing the system. A modern computer will have faster memory, faster disks, and a faster CPU and may be able to extract the data a lot more quickly. You will have to extract a disk image from the old system in order to virtualize it, but hopefully a single sequential pass at reading everything off its disk won't be too slow.
I don't know what the architecture of this system is, but I guess it is x86, which means it might be not too hard to virtualize (depending on how well the SCO OpenServer 6 OS agrees with the virtualization). You will have to use a hypervisor that supports full virtualization (not paravirtualization).
I finally solved the problem, running a query using another tool (not through MS Access or MS Excel) worked massively faster, ended up using DaFT (Database Fishing Tool) to SELECT INTO a text file. Processed all 50 million rows in a few hours.
It seems the dll driver I was using doesn't work well with any MS products.
I came by this page and was thinking about the best method to distribute my VbaProject.OTM file (located into %appdata%\Microsoft\Outlook\) to a bunch of ~30 users at my office. Is it better to simply copy/paste the OTM file onto the network and then copy/paste it back to all users' computers (manually or with a .bat) OR would it be better to use the method described in the link above to generate a OPS file and import it back with Proflwiz.exe? What's the difference?
We are all on Microsoft Office Outlook 2003 actually, we might upgrade to 2007 one day but still years from now.
Finally came up with some elements to deploy a Outlook VBA Project. There are a lot of ways to do this, but the easiest way to do so without installing anything and keeping the same methodology would be to run a OTM file directly from a server. I found out that the process outlook.exe has a parameter altvba that allows to specify another path to run the OTM file from. Here is en example:
outlook.exe /altvba "\\myServer\myFolder\myFile.otm"
This allows me to update only one file to get all computers updated. Obviously, if the file is big and the server's ping is on the high side, it may delay the launch of Outlook. The other problem with this method is that everybody will have to shut down Office if you want to update the OTM file on the server (and if you do work in an office where everyone uses Outlook, you do know that it is impossible to get everyone to shut it down at the same time, except if you code a macro to do so eventually). To prevent both those problems, I could setup a batch file to copy the server OTM file clientside everytime there is a new version (just have to check the NTFS last-modify attribute). This way, Outlook will boot with a local file, the batch file take 2-3 seconds to copy the file if needed (or will launch Outlook instantaneously) and there will be no problem updating the OTM file on the server. Users will have to start Outlook with the batch file (or with the slightly different outlook.exe path with the altvba parameter, so either way they need a different shortcut/file to start off the first time). One other advantage of the altvba is that it's still easy for the user to run Outlook without it (to see if the VBA is problematic or not in case Outlook is sluggish) and the file will remain unchanged after a Outlook reinitialization.
Others solutions include a COM complement that can be developed in a lot on languages including VB6 (no conversion needed from VBA). There is also a bunch of tools included into Microsoft Office XP Developer that could help getting the job done (not free however, especially if you need the most up-to-date version).
I have thousands of small CSV files I want to aggregate (with a little munging in-script first). They are on a NAS device, a "SNAP" Server to be more exact. I've had some success with VBA from Excel - doing about 700 files in about a minute, if I recall (was a month ago). Actually, it was half-success: the snap server is home to 80% pdfs and some proprietary-format files and only 20% CSVs. The Loop to test for filetype took the execution time north of 2 hours and the script apparently completely ignored date filtering I put in. The quick result or 'success' was on 700 copies of the CSVs I made and put on my C drive. I've been doing VBA scripting for almost 20 years, and I think I'm decent at it; I do a lot of CSV reading and writing from VBA the last 9 years. So my question is more about your experience with snap servers or NAS generally.
Can I not treat the snap server more or less like any drive/folder with VBA?
Would VBScript be more appropriate? (already using FileSystemObject, after all)
If I can use VBS can I store the script on the NAS and run it using taskscheduler?
I'd appreciate any tips or gotchas from you folks who have experience with snap servers!
Some thoughts on the choice of language:
VB Script is more lightweight than VBA in that it does not require MS Office to be installed. The syntax is similar so there is no real productivity difference.
Moving forward Powershell would be strongly recommended for Windows system admin tasks, general text file processing, etc.
Some thoughts on using the NAS server:
a) If running your script on a workstation you should be able to use a URI string \\myserver\myshare to connect to a share on the NAS. If not you may need to map a drive letter to that share before your script runs.
b) If you want to run your script on the NAS there are 2 things to consider: is the NAS OS locked so that you may not add your own scheduled task and is it Linux or some flavor of Windows. Many NAS products use embedded Linux so running a VBA or VBScript solution directly on the NAS may not work unless it is based on something like Embedded XP and you have access to Scheduled Tasks, etc.
Hope this helps...