using NotePad from Access: possible?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello,
I'm working on a smal DB which will act as a kind of an updater against
another db installed on users pc's.
This updaters will make changes/corrections to their data.
I would like to have this small db to write the actions taken on data on a
..txt file in order to let know the user what was going wrong with his data.
I wrote this code:

Option Compare Database
Private F As Object
Private wrkSec As Workspace
Private DBEng As Object
Private DBdaAgg As Database
Private centro As String
______________________________

Private Sub Command0_Click()
On Error GoTo HANDLER

Set fs = CreateObject("SCRIPTING.FILESYSTEMOBJECT")
Dim FirstAction As String
Dim STATUS As Boolean
Dim wrkSec As Workspace
Dim QualePath As String
Dim TBLdaAgg As DAO.Recordset
Dim TBLmaster As DAO.Recordset
Dim logStringa As String
Dim ErrorLine As Byte
Set DBEng = CreateObject("DAO.DBEngine.36")
Set F = fs.CREATETEXTFILE("C:\FARUS\LOG_20MAY2007.TXT", True)
F.writeline ("*********************************************")
F.writeline ("** UPDATER DEL 20 MAGGIO 2007 (R) **")
F.writeline ("*********************************************")
(other code follows)

but after many googling it comes out that it the SCRIPTING.FILESYSTEMOBJECT
is mostly used with ASP.
WHat has driven me crazy is that it worked fine on my pc and on other pcs
without the need to referencing any new .dll. But it doesn't run on user
machine: they all got error messages.
I cannot use WORD trough automation since most of the user have Access
runtime (I have deployes the db using the package wizard) and they don't have
Office installed.
I would simply use NotePad to create a .txt file to show what changes has
been done to data and to give hints to the users.

Is there any way to achieve this?

Thanks,
Rocco
 
Hi Rocco

The FileSystemObject is held within the VBA Object Library so will ship with
your distributed application automatically - no need to reference other
libraries.

1. Your coding is correct.
2. What is the Error message?
3. Does the folder exist on the offending PC's? I'm not sure if this would
cause an error if it wasn't but it might.
4. FileSystemObject is used extensively by VBA.
4. You say that you can't use Word automation as you users have Runtime
Access. This is not correct ! Word automation will work under Runtime without
any problems - I have many users working on this basis.

Cheers.

BW
 
If all you want to do is add text to a text file, you
don't need any other applications to do it.

Dim ifile
ifile = FreeFile
Open "c:\myfile.txt" For Append As #ifile
Print #ifile, "line1"
Close


(david)
 
I have noticed a difference, sometimes you need to say
IWSHRuntimeLibrary.FileSystemObject instead of scripting.FileSystemObject
right?
 
Hi David

As per my previous post, I think that rocco's most likely problem is that
the folder he's trying to create the text file in doesn't already exist. Your
coding, whilst elegant, would throw the same error.

So perhaps, testing for the folder first, then running your coding would
make sense:

On Error GoTo FolderAlreadyExists
Set cf = CreateObject("scripting.filesystemobject")
cf.createfolder ("C:\path to folder")
FolderAlreadyExists:
Set cf = nothing
.... your coding ...

Cheers.

BW
 
BeWyched said:
As per my previous post, I think that rocco's
most likely problem is that the folder he's trying
to create the text file in doesn't already exist. Your
coding, whilst elegant, would throw the same error.
Click to expand...

The Open for Append statement creates a file, if the specified file does not
already exits. I believe you will find that explained in Help on the Open
statement, in most versions of Access, at least back to and including,
Access 2.0. It also does not depend on the FileSystemObject, which is often
deleted and blocked by System Administrators for security.

And, in your pevious post, you stated that the "FileSystemObject is used
extensively by VBA" which is in error. FSO can be used _from_ VBA, but it is
not used _by_ VBA. If it were, that would imply that FSO was required to run
VBA, and as stated above, SYSADMINS often remove it from systems under their
control, and block its reinstallation -- and VBA runs just fine on those
systems without FSO.

Larry Linson
Microsoft Access MVP
 
Hi Larry

If you had read my post more carefully you would note that I said that 'most
likely problem is that the folder he's trying to create the text file in
doesn't already exist'. I am fully aware that the file would be created (as
clearly mentioned in the Help files), but the Method won't create a folder if
it doesn't exist (no mention in the Help files and it does throw an error on
my PC - Access 2003). I therefore stand by my suggestion that rocco should
test for the existence of the folder and create it if necessary.

Re FileSystemObject - I don't think differentiating between _from_ and _by_
serves any useful purpose. All I know is that I have created, and seen many
other applications, that have used FSO succesfully from/by/within VBA.

BW
 
Back
Top