(DOT) .SaveAsText Method 1

[MichaelRed]

I have read / seen numerous rererences to ths (hidden) method and it's compliment. I have tried a couple of the more straight forward implementations. Alas Alack and Awry no joy in mudville. The specifc Procedure:

Public Function SaveAllAsText(sPath)

    Dim vObject As Object
    Dim Idx As Integer
    Dim dbs As DAO.Database

    Set dbs = CurrentDb

    For Each vObject In dbs.Containers("Forms").Documents
        Application.SaveAsText acForm, vObject.name, sPath & "\" & vObject.name & ".xcf."
    Next

    For Each vObject In dbs.Containers("Reports").Documents
        Application.SaveAsText acReport, vObject.name, sPath & "\" & vObject.name & ".xcr"
    Next

    For Each vObject In dbs.Containers("Modules").Documents
        Application.SaveAsText acModule, vObject.name, sPath & "\" & vObject.name & ".xcm"
    Next

    For Each vObject In dbs.Containers("Scripts").Documents
        Application.SaveAsText acMacro, vObject.name, sPath & "\" & vObject.name & ".xcs"
    Next

    For Idx = 0 To dbs.QueryDefs.Count - 1
        If Left(dbs.QueryDefs(Idx).name, 4) <> "~sq_" Then
            Application.SaveAsText acQuery, dbs.QueryDefs(Idx).name, _
                                   sPath & "\" & dbs.QueryDefs(Idx).name & ".xcq"
        End If
    Next Idx

    Debug.Print "All done"

End Function

Returns an error "cannot open " & *** & file where the file name is the name of hte first object (always a FORM) in the numerous variations of the path. Some seem to have success with this, whilst others complain. Does anybody have any insight as to WHY the file name cannot be opened / created / accessed? I'm running Ms. A. ver 2k3 on XP Home from this location, if any of that matters.




MichaelRed

 

[RoyVidar]

This looks pretty much the same as thread705-751080 or Arvin Meyers

http://www.datastrat.com/Code/DocDatabase.txt.

I'm using the former, and only way I can get it to error with that error, is if the path/directory doesn't exist.

I copy/pasted your code to, with the same results.

Here's one more to add

[tt]application.saveastext 6, "", sPath & "\newdb.mdb"[/tt]

Roy-Vidar

 

[MichaelRed]

RoyVidar

Thanks. Rather obvious, just couldn'y ge my head around it. Thought I had copied and pasted the path from win explorer ... obviousness is that the err is between seat and keyboard.

I'm considering writting a utility to convert .MDB to regular plain old VB. I have always assumed the structures would be muchly the samesness. A quick look appears to confirm this. Some reasonably intensive search and replace in the header section to get started, but looks quite doable. Suprise -to me at least- is that Ms. A. seems to be more detailed in some respects. Again, perhaps it is necessary (obviously?) as it maintains these for ALL forms in the single space.

Again, thanks.






MichaelRed

 

[ddiamond]

RoyVidar,

I just gave you a star. For months I've been trying to figure out how to gather meta data about access databases. Your reply gave me the answer. Once everything is exported to text files, writing a program to gather the metadata is trivial.

- Dan

 

[MichaelRed]

To me, the "meta data" is pretty reasonably available from Ms. A. directly, and the availability is increasing with each release. I have generated a couple of 'projeects' which gather various levels of the meta data into seperate tables for various purposes. On one early adventure, this took the form of a comprehensive "cross reference" between each item of persistient data and its usage throughout the application. All the information was available from the MSys* files, although it did (and still can) take a bit of digging to ferret out the meaning of some of the descriptors.

My original quest (of this thread) is the persuit of a facillity to 'automatically' be ablt to translate an Ms. A. App to another basis (e.g. VB). This is somewhat more intensive, as (obviously) one needs to know a bit more about the app, than the data sections' meta data descriptors.

I continue to work towards this overall goal, but -as always- am constrained by having to contribute to the ongoing care and feeding of the monsters (aka Ms. Access db apps) which are used to run the businesses which offer some renumeration for these efforts.




MichaelRed

 

[ddiamond]

If often use a spec to import data from flat files or export data or queries to flat files. Is their anyway to save the spec as text?

 

[MichaelRed]

I know of no way to save the specs specifically as text. The specs should be'available' as part of the "system" tables per the Codd rules / deffinition of a relational database (e.g. "Self Documenting"). I recall (fuzzily at thips point) some discussions / threads reference IMEX or IMEXSPECS, but the tacle doesn't exist unless / until you create a spec. I have not had occassion to use this facility for a while, so do not have any handy examples. Please use 'search'/'advanced search' with appropiate key words.




MichaelRed

 

[JerryKlmns]

MichaelRed,

I see an extra dot there

    For Each vObject In dbs.Containers("Forms").Documents
        Application.SaveAsText acForm, vObject.name, sPath & "\" & vObject.name & ".xcf[b][red].[/red][/b]"
    Next

Normally(?!?) it is acceptable.... but you never know!

------------
ddiamond, you mean something different than this ?

DoCmd.TransferText acExportDelim,,"MSysIMEXColumns","C:\IMEXColumns.txt"

 

[ddiamond]

Thanks for the suggestion, MichaelRed and JerryKlmns. What you suggested will export the specs to a text file. And I searched MSysIMEXColumns which lead me to a thread referencing the website [URL unfurl="true"]http://support.microsoft.com/kb/155512/[/url]. This link shows you how to create a schema.ini file. What I haven't figured out how to modify the spec without opening the export dialog box and then clicking on the advanced tab. That is how I am currently doing it, but for slow queries this can be time consuming because the dialog box attempts to run your query. It appears that MSysIMEXColumns is read-only, and I can't figure how to create a spec from a schema.ini file.

 

[MichaelRed]

I think (cogito ergo loco?) that the IMEX specs can be read (and undestood?) and that undestanding provides the basis of creatint additional specs and / or schema.ini files.




MichaelRed

 

[JerryKlmns]

ddiamond,

Take a look at thread181-1085235. Schema.ini is my favorite.

----------
MichaelRed, what about the dot I mentioned?