none
MS Access 2003 Failure Creating File Error 3436

    Question

  • I am trying to use the TransferSpreadsheet
    action in VBA to export a table from Access 2003 to Excel 2003.
    When that step of the VBA code attempts to execute, I get an
    error "Failure creating file."

    DoCmd.TransferSpreadsheet acExport, , "T_Current", OutPutPathAndFileName, True, ""

    Any ideas?

    I have verified that the file exists and the path is
    correct. Thanks in advance.

    Thursday, September 22, 2011 8:36 PM

All replies

  • How did you declared and set the string OutPutPathAndFileName?

     


    Daniel van den Berg | Washington, USA | "Anticipate the difficult by managing the easy"
    Thursday, September 22, 2011 8:44 PM
  • I'm with Daniel - Show us how you are assigning the value to OutputPathAndFileName.  Also, just an FYI - if you have an optional argument that you aren't going to use, don't use "" in there.  Just don't include it or the comma if it is the last comma.  If it isn't the last comma then you just include the comma.

    So this would be what you would want:

    DoCmd.TransferSpreadsheet acExport, , "T_Current", OutPutPathAndFileName, True

    without the ending comma and quotes.  And just remember that the OutputPathAndFileName must also include the right backslashes for the file structure and also the file extension (.xls, .xlsx, .xlsm, etc.).


    Bob Larson, Access MVP 2008-2010, 2011
    Thursday, September 22, 2011 9:01 PM
  • Also in case of writing to Network Path, make sure you have the right permissions (Access, Read/Write etc.).

    That could also be a cause having this error.


    Daniel van den Berg | Washington, USA | "Anticipate the difficult by managing the easy"
    Thursday, September 22, 2011 9:11 PM
  • Hi all,

    Thank you for your replies to start with.

    Here it is

    Dim OutPutPathAndFileName As String

    OutPutPathAndFileName = DLookup("OutputPath", "T_CURRENT") & "\" & module & "_" & mode & "_" & runid & ".xls"

    So it takes a value from the column "OutputPath" of the table "T_CURRENT", and this is a local path.

    and it ends up being something like
    C:\Documents and Settings\CHOICLA\My Documents\Sherlock Output\20110921_Output_1546\Mod_Mode_20110921_1545.xls

    It has backslashes and extension xls.
    I do not write my output to network path, only local path, and I have all accesses (read/write, etc) to the folder and file.

    Let me try without double quotes for optional argument (but I am not convinced what that has to do with failure creating file...)

    Thanks,


    • Edited by clark_ussr Friday, September 23, 2011 1:33 PM
    Friday, September 23, 2011 1:26 PM
  • Hi again,

    What about module, mode and runid? Where are they come from?

    By the way "Module" is a Reserved Word in Access, you might change this into something else.

     

    Can you place a Debug.Print OutPutPathAndFileName and see in immediate window, what value is shown?

    You might also place a breakpoint at the line OutPutPathAndFileName, and with F8 step by step go through code and see where the code errors.

     

    Hope this helps,


    Daniel van den Berg | Washington, USA | "Anticipate the difficult by managing the easy"
    Friday, September 23, 2011 2:50 PM
  • Hi,

    Maybe I should elaborate my error a bit more.

    First, thank you, I didn't know module was a reserved word in MS Access.

    and Module and Mode are defined as follows:

    Dim module As String
    Dim mode As String
        
    module = DLookup("Module", "T_CURRENT")
    mode = IIF(DLookup("ProcessMethod", "T_CURRENT") = "E", "EMR", "CPH")

    runid is just yyyymmdd_hhmm format, which is used everywhere and gave me no problem so far.

    I did try with F8 to view OutputPathAndFileName closely, and I did not see anything weird (Module was "LI_Helium", and Mode was EMR as ProcessorMethod was "E").

    Third, this error does not always occur.
    I took this portion out and tested separately and I did not get any error.
    I get this error after a lot of SQL transaction between MS Access and MS SQL Server.
    So I thought it could be some memory issue, so I tried to use stuff like DoEvents and all, but didn't do the trick.

    I am testing this on a desktop machine (XP) but I have been having a suspicion that a free disk space might be causing this because this same error does not occur in my laptop with the same OS, CPU, Similar Memory, but different amount of free disk space, except for one time where I was having a free disk space of below 50GB.  So I was wondering if you have seen or heard such case where people see this error when they run out of space.  For some reason, running MS Access & MS SQL Server & MS Excel at the same time seems to create a heavy usage of disk space, but I cannot verify such suspicion on my own.

    Thanks

     


    • Edited by clark_ussr Friday, September 23, 2011 3:57 PM
    Friday, September 23, 2011 3:56 PM
  • I don't suspect that Free Disk Space is an issue in this case.

    Did you tried to change the module in something else, and see if that helps?

     

    I suspect that using DLookup() Method may also play part in this, what can slow down the process. What is the size of table T_CURRENT?

    You might use a Stored procedure or Pass-through query instead to retrieve the values you need in Access from your SQL Server, so you can speed up the process.

    Just my 2 cts ...

     


    Daniel van den Berg | Washington, USA | "Anticipate the difficult by managing the easy"
    Friday, September 23, 2011 4:15 PM
  • I am still running the program (that part is sitting at the end and it takes about 2 hours to complete this run)

    Why do I not just test "that portion" ?  Because I did test that portion itself and it didn't fail.

    T_CURRENT is a table that contains environment information in a single record with about 10 columns, so size is tiny (almost nothing)

    I did have this table in SQL Server but I moved it to MS Access because of some particular situation of the program.  but calling stored procedure from MS SQL Server in this case doesn't necessarily improve performance as it is a single record table.

    Thanks Dan

    Friday, September 23, 2011 4:46 PM
  • You are welcome Clark! :)

     

    > I am still running the program (that part is sitting at the end and it takes about 2 hours to complete this run) <

    Wow, 2 hours is a long run ... Why it takes that long?

    Well hope you get this resolved, its frustrating to not know exactly what is causing this.

     


    Daniel van den Berg | Washington, USA | "Anticipate the difficult by managing the easy"
    Friday, September 23, 2011 5:03 PM
  • This program performs a lot of queries (mostly stored procedures, and tables involved are huge, over a million records per table, etc), and it takes number of years as input and it takes longer depending on the number of years.

    Debug.print statement showed the same content as before, and this time, I did not get an error, but the program just ended there...

    I open up the Windows Processes and I do not see Excel.exe... not sure what is going on here...

     



    • Edited by clark_ussr Friday, September 23, 2011 6:53 PM
    Friday, September 23, 2011 6:47 PM
  • > Debug.print statement showed the same content as before, and this time, I did not get an error, but the program just ended there...

    I open up the Windows Processes and I do not see Excel.exe... not sure what is going on here... <

     

    Is the file created or not?


    Daniel van den Berg | Washington, USA | "Anticipate the difficult by managing the easy"
    Friday, September 23, 2011 6:56 PM
  • No, file was not created.
    • Edited by clark_ussr Friday, September 23, 2011 9:16 PM
    Friday, September 23, 2011 6:58 PM
  • I have no idea how your whole process is what you started and if above code you posted is all the code what runs, so I cannot tell whats going on either.

     


    Daniel van den Berg | Washington, USA | "Anticipate the difficult by managing the easy"
    Friday, September 23, 2011 7:03 PM
  • I have read somewhere that incorrect version can cause this problem.

    In my case I leave it blank (the second parameter), which uses a default value (acSpreadsheetTypeExcel8 or acSpreadsheetTypeExcel9)

    DoCmd.TransferSpreadsheet acExport, , "T_Current", OutPutPathAndFileName, True, ""

    These acSpreadsheetTypeExcel8 or acSpreadsheetTypeExcel9 are Excel 2000 Format.

    Since I am using MS Access 2003, I assume MS Excel would be 2003 and that would be acSpreadsheetTypeExcel11, but this is not supported in MS Access 2003.

    Do you think this can be a problem potentially?

    Friday, September 23, 2011 11:49 PM
  • The default for TransferSpreadsheet in Access 2003, when you leave it blank, is acSpreadsheetTypeExcel8, see this thread of MSDN:

    http://msdn.microsoft.com/en-us/library/aa220766%28v=office.11%29.aspx

     

    I don't think its the cause of your problem. The question remains what the cause is.

    If you type the path hardcoded, and only runs the TransferSpreadsheet command, what happen?

     

    Just try to eliminate all possible causes.

     


    Daniel van den Berg | Washington, USA | "Anticipate the difficult by managing the easy"
    Saturday, September 24, 2011 12:31 AM
  • If I try the hard coded path, there is no difference.

    Also, keep in mind that the same code gives me no error if I run it on my laptop with the same XP SP3 installed.

    Let me ask a simple question.

    Do I need to run

     

        Call Excel.Application.Workbooks.Open(OutPutPathAndFileName)

        Set excelworkbook = Excel.ActiveWorkbook

     

    before I run DoCmd.TransferSpreadsheet acExport, , "T_Current", OutPutPathAndFileName, True ?

    because I don't have them right now. 

    Thanks again,


    • Edited by clark_ussr Saturday, September 24, 2011 10:05 PM
    Saturday, September 24, 2011 9:49 PM
  • How can you open the FileName, which is not yet created by the TransferSpreadsheet method?

    It would be the other way around, first create the new Excel file, then you would be able to open it, in case there is a File created ofcourse.

    The TransferSpreadsheet Method itself is sufficient to export the data to an Excel file.

     

    Couple of things you might try and check on your Desktop:

    - Any missing references? VBA Window > Tools > References >

    - Did you tried to set a breakpoint at the state of your code and go through the whole process step by step pressing the F8 button?

    - Has the Desktop the same Office 2003, with current Updates installed? Simular as your laptop?

     

    Hope this helps,


    Daniel van den Berg | Washington, USA | "Anticipate the difficult by managing the easy"
    Sunday, September 25, 2011 2:57 AM
  • Hi Daniel,

    First of all, I really appreciate you're not giving up yet as many people do.

    This is a type of issue where I find a bunch of suggestions from google search, but get only generic answers that don't really apply to a specific situation as mine.

    Clearly, Microsoft should provide some insight on "why the same MS Access VBA code works on a laptop, but not on desktop even though the environment is the same?"

    Yes, after I posted, I realized that calling TransferSpreadsheet alone should be able to create the excel file given the path.

    Now you're beginning to give me some right approach to try here.

    1) VBA Window > Tools > References
    I did not talk about this previously, but my laptop and desktop both have the following references.

    Visual Basic For Applications,
    Microsoft Access 11.0 Object Library,
    Microsoft DAO 3.6 Object Library,
    Microsoft ActiveX Data Objects 2.1 Library,
    OLE Automation,
    Microsoft Excell 11.0 Object Library,
    Lotus Domino Objects,
    Lotus Notes Automation Classes

    Please let  me know if you believe any mandatory reference is missing here.

    2) Yes, I have used the breakpoint and F8 to see this step by step on numerous times, but that did not give me any sign or clue.  I tried Debug.print and MsgBox also.  The path does not contain anything unusual unless MS Acces/Excel does not like space in folder name.

    3) I checked the system information on both machines, and they are exactly the same.
    MS Access version = 11.0
    MS Excel version = 11.0
    Jet version = 4.0
    ADO version = 2.8
    VBA version = 6.05

    Note: There is a "compatibility pack for the 2007 office system" installed on both machines, and I am not sure if that can have an impact on this issue.

    Sunday, September 25, 2011 4:51 PM
  • One thing that has started is...

    This code

    DoCmd.TransferSpreadsheet acExport, , "T_Current", MyHardcodedPath, True

    is called within a function

    and when it is executed, the flow exits the function right away... I have no idea why that happens...

    Sunday, September 25, 2011 6:07 PM
  • Re 1) References:

    As long as there is no Reference marked as MISSING, then it seems ok.

    Re 2) and 3)

    At least you have the code analyzed and the software version are simular.

    Re) Compatibility pack for the 2007 office system, I do hope you had all High-Priority Updates installed before installing the compatibility pack, see note:

    Users of the Microsoft Office XP and 2003 programs Word, Excel, or PowerPoint—please install all High-Priority updates from Microsoft Update before downloading the Compatibility Pack.

     

    Can you post the Function by any change, to see if there is anything what might cause the Function not to work propperly?

     


    Daniel van den Berg | Washington, USA | "Anticipate the difficult by managing the easy"
    Sunday, September 25, 2011 7:39 PM
  • Hi all,

    Thank you for your replies to start with.

    Here it is

    Dim OutPutPathAndFileName As String

    OutPutPathAndFileName = DLookup("OutputPath", "T_CURRENT") & "\" & module & "_" & mode & "_" & runid & ".xls"

    So it takes a value from the column "OutputPath" of the table "T_CURRENT", and this is a local path.

    and it ends up being something like
    C:\Documents and Settings\CHOICLA\My Documents\Sherlock Output\20110921_Output_1546\Mod_Mode_20110921_1545.xls

    It has backslashes and extension xls.
    I do not write my output to network path, only local path, and I have all accesses (read/write, etc) to the folder and file.

    Let me try without double quotes for optional argument (but I am not convinced what that has to do with failure creating file...)

    Thanks,



    According to the above code the T_CURRENT table must have only one record as the DLookUP function is missing the qualifier parameter.  It must also contain the login userid of the current user since that is part of the path.  In your example at least this portion of the full path file name "C:\Documents and Settings\CHOICLA\My Documents\Sherlock Output" must come from the OutputPath field.

    How does the login userid get updated?

    Also your transfertext statement is using T_CURRENT as the source.  Are you really exporting a single record?


    http://www.saberman.com
    Sunday, September 25, 2011 8:39 PM
  • Hi all,

    Thank you for your replies to start with.

    Here it is

    Dim OutPutPathAndFileName As String

    OutPutPathAndFileName = DLookup("OutputPath", "T_CURRENT") & "\" & module & "_" & mode & "_" & runid & ".xls"

    So it takes a value from the column "OutputPath" of the table "T_CURRENT", and this is a local path.

    and it ends up being something like
    C:\Documents and Settings\CHOICLA\My Documents\Sherlock Output\20110921_Output_1546\Mod_Mode_20110921_1545.xls

    It has backslashes and extension xls.
    I do not write my output to network path, only local path, and I have all accesses (read/write, etc) to the folder and file.

    Let me try without double quotes for optional argument (but I am not convinced what that has to do with failure creating file...)

    Thanks,



    According to the above code the T_CURRENT table must have only one record as the DLookUP function is missing the qualifier parameter.  It must also contain the login userid of the current user since that is part of the path.  In your example at least this portion of the full path file name "C:\Documents and Settings\CHOICLA\My Documents\Sherlock Output" must come from the OutputPath field.

    How does the login userid get updated?

    Also your transfertext statement is using T_CURRENT as the source.  Are you really exporting a single record?


    http://www.saberman.com

    Yes, T_CURRENT table has only one record, and yeah, I am exporting a single record only.
    but where should the "current login userid" be contained? I do not include any login info to anything as it's just windows authentication.
    Monday, September 26, 2011 1:20 PM
  • Let me write some update here.

    After I removed the comma and quotes, I stopped receiving the error "Failure Creating File", but the code that follows stopped working.

    ---> Call Excel.Application.Workbooks.Open (OutPutPathAndFileName)
    ---> 'Then add a page, give a name, save and close.

    As soon as the cursor executes this line, it exits this entire function.

    The previous developer used DoCmd.TransferSpreadsheet to add the single record into this Excel file, but after the review, this was not necessary because he has a separate function to add it.

    Since I just needed to create this new file with the name, I decided to try creating an Excel file explicitly, add a page, give a name, save and close as follows:

        Set oExcel = CreateObject("Excel.Application")
        Set oBook = oExcel.Workbooks.Add
        oBook.Sheets(3).Delete
        oBook.Sheets(2).Delete
        oBook.Sheets(1).Name = "Summary"
        oBook.SaveAs OutPutPathAndFileName
        oExcel.Quit
        Set oExcel = Nothing

    This code worked.

    I used this code by suggestion from these links http://support.microsoft.com/kb/319832 and http://support.microsoft.com/kb/178510

    but other functions that follow containing code such as

        Call Excel.Application.Workbooks.Open(OutPutPathAndFileName)

    started giving me this error "Error 462: The remote server machine does not exist or is unavailable."

    The links above indicate that I have to make everything explicit, so I am going to change all code with explicit object creation for Excel.Application, Excel.Workbooks, etc.

    If this would work, I will give update here.

    If this works, then I would still like to find out "when" this code change is needed.

    Why my desktop, but not laptop...

    Monday, September 26, 2011 1:35 PM
  •     Set oExcel = CreateObject("Excel.Application")
        Set oBook = oExcel.Workbooks.Add
        oBook.Sheets(3).Delete
        oBook.Sheets(2).Delete
        oBook.Sheets(1).Name = "Summary"
        oBook.SaveAs OutPutPathAndFileName
        oExcel.Quit
        Set oExcel = Nothing

    This code worked.

    Yeah, it should work. I was about to suggest late binding for your Excel Reference as you state the version maybe different in user PC.
    • Edited by AccessVandal Tuesday, September 27, 2011 1:24 AM
    Tuesday, September 27, 2011 1:23 AM
  • Clearly, Microsoft should provide some insight on "why the same MS Access VBA code works on a laptop, but not on desktop even though the environment is the same?"

    Hi clark_ussr,

    I bet it is a timing problem. In my situation such a case has occured when the creation or deletion of an external file was involved.

    For instance a similar situation with the renaming of a Reference database. It worked perfectly on certain computers, but not on others. Adding a couple of DoEvents did not solve the problem either. Only when I build in a time delay (just a loop counting to 100000) it worked on all systems.

    I did not yet optimize the number of DoEvents and/or the time delay, because I basically tackled the problem and there were some other priorities.

     

    Imb.

    Tuesday, September 27, 2011 7:46 AM
  • Clearly, Microsoft should provide some insight on "why the same MS Access VBA code works on a laptop, but not on desktop even though the environment is the same?"

    Hi clark_ussr,

    I bet it is a timing problem. In my situation such a case has occured when the creation or deletion of an external file was involved.

    For instance a similar situation with the renaming of a Reference database. It worked perfectly on certain computers, but not on others. Adding a couple of DoEvents did not solve the problem either. Only when I build in a time delay (just a loop counting to 100000) it worked on all systems.

    I did not yet optimize the number of DoEvents and/or the time delay, because I basically tackled the problem and there were some other priorities.

     

    Imb.


    Hi Imb,

    At one point, I also thought that it was a timing issue because the code "DoCmd.TransferSpreadsheet" works if I put it at the top of the function, but doesn't work if I put it at the bottom of the function, although all it does is adding a MS Access table to an Excel file (so creating this file simultaneously.)

    So I tried DoEvents as well as time delay of 10 seconds, 15 seconds, and 20 seconds etc.

    DoEvents was either taking too much time or won't let go of CPU, so I couldn't apply that.

    Giving a delay of 10, 15, 20 seconds, etc. worked only "sometimes".

    You can imagine the combination of number of test cases that I can come up with in order to see "which amount of delay works consistently, but not sometimes", as well as "other priorities" as you mentioned.  so I decided not to deal with timing.

    Thanks for sharing your case though as I believe people, or rather MS, should be aware of this kind of situation.

    Cheers,

    Tuesday, September 27, 2011 12:59 PM
  •     Set oExcel = CreateObject("Excel.Application")
        Set oBook = oExcel.Workbooks.Add
        oBook.Sheets(3).Delete
        oBook.Sheets(2).Delete
        oBook.Sheets(1).Name = "Summary"
        oBook.SaveAs OutPutPathAndFileName
        oExcel.Quit
        Set oExcel = Nothing

    This code worked.

    Yeah, it should work. I was about to suggest late binding for your Excel Reference as you state the version maybe different in user PC.

    Yeah, it works great.
    but both Desktop and Laptop say Excel version being used is 11.
    Maybe there is an area where I can get more accurate information on "version" ?
    Tuesday, September 27, 2011 1:02 PM
  • I want to share one more issue with you guys while at it.

    If I run the following command

    DoCmd.TransferText acExportDelim, , "MissingKeys", DLookup("OutputPath", "T_Current") & "\" & DLookup("Module", "T_Current") & "_MissingKeys_" & runid & ".txt", True

    or

    DoCmd.TransferText acExportDelim, "ExportTemplate Link Specification", "ExportTemplate", DLookup("OutputPath", "T_Current") & "\" & DLookup("Module", "T_Current") & "_BoxOutput_" & runid & ".txt", True

    the execution fails without producing any message (it just stops execution right after that code), again, -->from time to time<--

    Does anybody know any replacement code for this...

    Tuesday, September 27, 2011 2:42 PM
  • Okay folks,

    I would like to share what I have found thru this experience.

    What either TransferText or TransferSpreadsheet with Export option does is basically to create a text file or an Excel file and put the MS Access table content in the created file.

    For some darned reason, under "certain" environment, they just fail.

    In my case, it failed in Desktop.  (Never failed in Laptop)  I know that is not enough to describe the difference, but all other software deployment or configurations are the same.

    TransferText fails with "Cannot find installable ISAM" error.

    TransferSpreadsheet fails with "Failure Creating File" error.

    Sometimes, they fail silently.

    When I replaced them with explicit file creation code using CreateObject("Excel.Application") or CreateObject("Scripting.FilSystemObject"), the error is gone.

    Well, that's all.

    Hate to leave it this way, but I believe there are some people who know what this is all about out there, and hopefully they can explain it better...

    Thanks for all the replies and help.

    Cheers,

    Tuesday, September 27, 2011 8:49 PM
  • Hi again,

    If it works on your Laptop, and not on your Desktop, their might be something not right with the Desktop and with the Office installed.

    Did you run this on any other Desktop?

     

    The "Cannot find installable ISAM" error on your TransferText method leads me to this KB article of Microsoft:

    http://support.microsoft.com/kb/283881

    You might check the article and see if the resolution they offer helps.

     

    Other thing what came to mind, is the Access Database (I assume the FrontEnd), the same version you use on the Laptop as on the Desktop?

     

    Hope this brings some light in the darkness...

     

    Cheers,

     

     

     


    Daniel van den Berg | Washington, USA | "Anticipate the difficult by managing the easy"
    Wednesday, September 28, 2011 2:54 AM
  • Yeah, it works great.
    but both Desktop and Laptop say Excel version being used is 11.
    Maybe there is an area where I can get more accurate information on "version" ?

    Here's Tony's site about late binding.

    http://www.granite.ab.ca/access/referencetroubles.htm

    http://www.granite.ab.ca/access/latebinding.htm

    Here's Doug's site on checking References.

    http://www.accessmvp.com/djsteele/AccessReferenceErrors.html

    Hope it helps.

    Wednesday, September 28, 2011 2:55 AM
  • Hi again,

    If it works on your Laptop, and not on your Desktop, their might be something not right with the Desktop and with the Office installed.

    Did you run this on any other Desktop?

     

    The "Cannot find installable ISAM" error on your TransferText method leads me to this KB article of Microsoft:

    http://support.microsoft.com/kb/283881

    You might check the article and see if the resolution they offer helps.

     

    Other thing what came to mind, is the Access Database (I assume the FrontEnd), the same version you use on the Laptop as on the Desktop?

     

    Hope this brings some light in the darkness...

     

    Cheers,

     

     

     


    Daniel van den Berg | Washington, USA | "Anticipate the difficult by managing the easy"

    Hi Daniel,

    I have checked that site quite a while ago, and I tried their fix, but didn't work at all.

    MS Access versions on the desktop & laptop are the same (as I previously mentioned).

    I also tried it against another desktop with the same version of MS Access, as well as all other Office product versions and OS and etc, and still same issue.

    Thanks,
    Thursday, September 29, 2011 6:01 PM
  • Have you tried checking the References yet?

    If it is still not the problem, I would suggest a de-compile of your db but do a back-up first before doing this. (assuming you did a compact & repair before)

    Friday, September 30, 2011 1:17 AM
  • Have you tried checking the References yet?

    If it is still not the problem, I would suggest a de-compile of your db but do a back-up first before doing this. (assuming you did a compact & repair before)


    I repeat.  I have checked all the references, and they are not the problem.  Thanks.
    How do you "de-compile" of my db?

    DoCmd.TransferText seems to produce the same problem everytime some environment changes.
    In my case, if a different user logs into the machine that has my MS Access application, DoCmd.TransferText starts to act up.
    Fails silently for no reason.

    Now I think this is 100% timing issue, but I am just sick and tired of why Microsoft does not deal with this problem somewhere.
    Tuesday, October 4, 2011 7:55 PM
  • I create a shortcut like this

    "C:\Program Files\Microsoft Office\Office12\MSACCESS.EXE" /decompile

    After doubleclick it opens Access

    Select your app and open

    That is the end of decompile

    then you compile by opening VBA - debug - compile

    close db

    use it


    Chris Ward
    Tuesday, October 4, 2011 8:41 PM

  • I am using DoCmd.TransferSpreadsheet acExport, , "Export Bid", strFileName, True

    and getting different results ranging from runtime error 3436, quiet failure to create file, sometimes goes away with a compact/ repair, sometimes not. Looks buggy to me. July 2013 Using Office 2010

    Friday, July 12, 2013 12:03 AM