How To Import Modified Database Objects
Randy Yates
(but for other reasons as well), I would like my work flow in Access to
go like this:
1. Export existing database objects from Access to operating system file system:
Public Function ExportDatabaseModules(sExportLocation As String)
On Error GoTo Err_ExportDatabaseModules
Dim accObj As AccessObject
For Each accObj In CurrentProject.AllModules
Application.SaveAsText acModule, accObj.Name, sExportLocation & "Module_" & accObj.Name & ".bas"
Next
For Each accObj In CurrentProject.AllForms
Application.SaveAsText acForm, accObj.Name, sExportLocation & "Form_" & accObj.Name & ".bas"
Next
For Each accObj In CurrentProject.AllReports
Application.SaveAsText acReport, accObj.Name, sExportLocation & "Report_" & accObj.Name & ".bas"
Next
Exit_ExportDatabaseModules:
Exit Function
Err_ExportDatabaseModules:
MsgBox Err.Number & " - " & Err.Description
Resume Exit_ExportDatabaseModules
End Function
2. Edit object (e.g., a form) on operating system file system using
desired editor.
3. Import modified objects back into Access:
Public Function ImportDatabaseModules(sImportLocation As String)
On Error GoTo Err_ImportDatabaseModules
Dim accObj As AccessObject
For Each accObj In CurrentProject.AllModules
Application.LoadFromText acModule, accObj.Name, sImportLocation & "Module_" & accObj.Name & ".bas"
Next
For Each accObj In CurrentProject.AllForms
If accObj.Name <> "TransferDatabaseModulesF" Then
Application.LoadFromText acForm, accObj.Name, sImportLocation & "Form_" & accObj.Name & ".bas"
End If
Next
For Each accObj In CurrentProject.AllReports
Application.LoadFromText acReport, accObj.Name, sImportLocation & "Report_" & accObj.Name & ".bas"
Next
Exit_ImportDatabaseModules:
Exit Function
Err_ImportDatabaseModules:
MsgBox Err.Number & " - " & Err.Description
Resume Exit_ImportDatabaseModules
End Function
4. Repeat 2-4 as needed.
However, I've noticed that, while Modules are imported successfully this
way, forms are not (reports probably aren't either but I haven't checked
them yet). I suspect it has something to do with either the checksum at
the top or the assorted GUID or NameMaps within the file (see below for
an example).
Any hints/pointers/thoughts/wild-ass-guesses on how this can be done
would be appreciated!
--Randy
Version =20
VersionRequired =20
Checksum =547744138
Begin Form
RecordSelectors = NotDefault
NavigationButtons = NotDefault
AllowDesignChanges = NotDefault
DefaultView =0
TabularFamily =55
PictureAlignment =2
DatasheetGridlinesBehavior =3
GridX =24
GridY =24
Width =4320
DatasheetFontHeight =10
ItemSuffix =3
Top =600
Right =6105
Bottom =4095
DatasheetGridlinesColor =12632256
RecSrcDt = Begin
0x3afc83cdffc6e240
End
GUID = Begin
0xc3dd421190954d4d94f8e5f6b9da7292
End
NameMap = Begin
0x0acc0e5500000000000000000000000000000000000000000c00000004000000 ,
0x0000000000000000000000000000
End
DatasheetFontName ="Arial"
FilterOnLoad =0
DatasheetBackColor12 =16777215
ShowPageMargins =0
DisplayOnSharePointSite =0
DatasheetGridlinesColor12 =12632256
Begin
Begin CommandButton
FontSize =8
FontWeight =400
ForeColor =-2147483630
FontName ="Tahoma"
LeftPadding =30
TopPadding =30
RightPadding =30
BottomPadding =30
GridlineStyleLeft =0
GridlineStyleTop =0
GridlineStyleRight =0
GridlineStyleBottom =0
GridlineWidthLeft =1
GridlineWidthTop =1
GridlineWidthRight =1
GridlineWidthBottom =1
End
Begin Section
Height =2280
BackColor =-2147483633
Name ="Detail"
GUID = Begin
0xf8270980e15e4d469fbc91e452cd9f48
End
Begin
Begin CommandButton
OverlapFlags =85
Left =2460
Top =240
Height =840
ForeColor =128
Name ="btnImportDatabaseModules"
Caption ="Import Database Modules"
OnClick ="[Event Procedure]"
GUID = Begin
0xc58fd6c730d1814ab10a9e81782f9081
End
End
Begin CommandButton
OverlapFlags =85
Left =480
Top =240
Height =840
TabIndex =1
ForeColor =6723891
Name ="btnExportDatabaseModules"
Caption ="Export Database Modules"
OnClick ="[Event Procedure]"
GUID = Begin
0x943060adac5e064b9c369daa1836652a
End
End
Begin CommandButton
OverlapFlags =85
Left =1440
Top =1440
TabIndex =2
Name ="btnTest"
Caption ="Test"
OnClick ="[Event Procedure]"
GUID = Begin
0x4cd6cb1f215f7849be9ae7c8f4a25cbe
End
LayoutCachedLeft =1440
LayoutCachedTop =1440
LayoutCachedWidth =2880
LayoutCachedHeight =1800
End
End
End
End
End
CodeBehindForm
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = True
Attribute VB_PredeclaredId = True
Attribute VB_Exposed = False
Option Compare Database
Option Explicit
Private sModuleLocation As String
Private Sub btnExportDatabaseModules_Click()
sModuleLocation = Access.Application.CodeProject.Path + "\bas\"
Call ExportDatabaseModules(sModuleLocation)
End Sub
Private Sub btnImportDatabaseModules_Click()
sModuleLocation = Access.Application.CodeProject.Path + "\bas\"
Call ImportDatabaseModules(sModuleLocation)
End Sub
Private Sub btnTest_Click()
Call TransferTest
End Sub
--
Randy Yates % "She has an IQ of 1001, she has a jumpsuit
Digital Signal Labs % on, and she's also a telephone."
mailto://ya...@ieee.org %
http://www.digitalsignallabs.com % 'Yours Truly, 2095', *Time*, ELO
hbinc
Hi Randy,
I have no answer to your question on this moment, but I was very
interested in your question as such. And especially in the question
behind your question.
Personally I have no problems with the VBA-editor. Far more problems I
had with the overview of what is used in which form, querydef, report
etc. in all the different database-applications. Especially when you
want to change something, how do you know you did not forget anything.
I you export ALL definitions to an external editor, it a matter of a
simple search to find all instances that need to be changed.
Is this the reason for your export operation?
Another reason to export and edit externally form Access, is to do the
editing on one place, and later import it in the different databases.
In this way it is not necessary to do the changes in all databases. In
fact, this is the way I do my changes, but through VBA-editing.
Besides of that I like to learn more on the other reasons not to use
the VBA-editor.
Regards, HBInc.
Randy Yates
> [...]
> Hi Randy,
>
> I have no answer to your question on this moment, but I was very
> interested in your question as such. And especially in the question
> behind your question.
>
> Personally I have no problems with the VBA-editor. Far more problems I
> had with the overview of what is used in which form, querydef, report
> etc. in all the different database-applications. Especially when you
> want to change something, how do you know you did not forget anything.
> I you export ALL definitions to an external editor, it a matter of a
> simple search to find all instances that need to be changed.
> Is this the reason for your export operation?
>
> Another reason to export and edit externally form Access, is to do the
> editing on one place, and later import it in the different databases.
> In this way it is not necessary to do the changes in all databases. In
> fact, this is the way I do my changes, but through VBA-editing.
>
> Besides of that I like to learn more on the other reasons not to use
> the VBA-editor.
>
> Regards, HBInc.
Hey,
There are potentially dozens of reasons, but basically it's a matter
of having the ability to use the operating system and toolsets to
do various things, many of them very simple but powerful. Examples:
1. Using "grep" to find stuff
2. Automating a massive change by defining a lisp function (emacs
is my editor and it includes a version of lisp you can use in
editing).
3. Maintaining source control (version control) over items
independently.
4. Using your favorite diff tool (mine is tkdiff) to see differences
between versions.
etc.
--
Randy Yates % "Maybe one day I'll feel her cold embrace,
Digital Signal Labs % and kiss her interface,
mailto://ya...@ieee.org % til then, I'll leave her alone."
http://www.digitalsignallabs.com % 'Yours Truly, 2095', *Time*, ELO
Randy Yates
> [...]
> Personally I have no problems with the VBA-editor. Far more problems I
> had with the overview of what is used in which form, querydef, report
> etc. in all the different database-applications. Especially when you
> want to change something, how do you know you did not forget anything.
> I you export ALL definitions to an external editor, it a matter of a
> simple search to find all instances that need to be changed.
> Is this the reason for your export operation?
Yes, that is certainly one of them.
--
Randy Yates % "She's sweet on Wagner-I think she'd die for Beethoven.
Digital Signal Labs % She love the way Puccini lays down a tune, and
mailto://ya...@ieee.org % Verdi's always creepin' from her room."
http://www.digitalsignallabs.com % "Rockaria", *A New World Record*, ELO
paii, Ron
from a text file.
Application.SaveAsText acForm,"Form Name", "Export file name"
Application.LoadFromText acForm, "Form Name", "Inport file name"
Search "Export all database objects into text files" for more.
"Randy Yates" <ya...@ieee.org> wrote in message
news:m3ws2g9...@ieee.org...
paii, Ron
Need more Coffee this AM.
"paii, Ron" <no...@no.com> wrote in message
news:hc9d8v$q5p$1...@news.eternal-september.org...
David W. Fenton
news:798eac1a-12dd-485e...@g23g2000yqh.googlegroups.co
m:
> Besides of that I like to learn more on the other reasons not to
> use the VBA-editor.
I think there is not even a single good reason to avoid the VBE.
That way lies completel insanity.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
![Tony Toews [MVP]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjVFNFhAO8kxGtutFBSPYzx5Lbrrty7WRKPHNhjuWtTEHvsoQdk=s40-c)
Tony Toews [MVP]
>There are potentially dozens of reasons, but basically it's a matter
>of having the ability to use the operating system and toolsets to
>do various things, many of them very simple but powerful. Examples:
>
> 1. Using "grep" to find stuff
I really, really like the free MZTools find button. It has a screen showing you each
line that contains the text so you can get an overall view of where that text, such
as a variable, is used.
I also really, really like the Procedure Callers button as it shows where the current
sub/function is being called from.
> 2. Automating a massive change by defining a lisp function (emacs
> is my editor and it includes a version of lisp you can use in
> editing).
FWIW you can programmatically fill the Find/Replace combo boxes in Rick Fisher's Fnid
and Replace tool. I don't recall the details but you can insert records into a
table in his add0in..
Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a free, convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/
Tony Toews [MVP]
>Sorry, ignore the previous post, I didn't see you were using SaveAsText.
>Need more Coffee this AM.
<smile> Yeah, I know that feeling.
Randy Yates
> hbinc <j.van...@hccnet.nl> wrote in
> news:798eac1a-12dd-485e...@g23g2000yqh.googlegroups.co
> m:
>
>> Besides of that I like to learn more on the other reasons not to
>> use the VBA-editor.
>
> I think there is not even a single good reason to avoid the VBE.
> That way lies completel insanity.
All I can say is, different strokes for different folks. If all you
ever do in your career is write visual basic code, then this would
be insane.
However, if you write embedded assembly/C/C++ on multiple platforms and
toolsets, application-level C/C++ (i.e., command line tools), GUI C++
(e.g., wxWidgets), LISP (two different flavors), bash scripts, etc.,
etc., etc., then having a different development environment for each is
insanity.
--
Randy Yates % "She tells me that she likes me very much,
Digital Signal Labs % but when I try to touch, she makes it
mailto://ya...@ieee.org % all too clear."
http://www.digitalsignallabs.com % 'Yours Truly, 2095', *Time*, ELO
Chuck Grimsby
wrote:
> hbinc <j.van.g...@hccnet.nl> wrote innews:798eac1a-12dd-485e...@g23g2000yqh.googlegroups.co
> m:
> > Besides of that I like to learn more on the other reasons not to
> > use the VBA-editor.
> I think there is not even a single good reason to avoid the VBE.
> That way lies completel insanity.
Oh, do this from time to time.
Save an object for transport to another DB, mass changes to objects,
control names, and the like, archival purposes, etc.,
but I also do it to "fix" things like when labels get re-attached to
the wrong text boxes and such. Sometimes it's just easier/faster to
do do things outside of Access.
Besides, it's actually kind of fun from time to time!
David W. Fenton
news:9ffac39e-c81f-4834...@d5g2000yqm.googlegroups.com
:
> On Oct 28, 10:22�pm, "David W. Fenton"
> <XXXuse...@dfenton.com.invalid> wrote:
>> hbinc <j.van.g...@hccnet.nl> wrote
>> innews:798eac1a-12dd-485e-a386-0c9d6c1
> b0...@g23g2000yqh.googlegroups.co
>> m:
>> > Besides of that I like to learn more on the other reasons not
>> > to use the VBA-editor.
>
>> I think there is not even a single good reason to avoid the VBE.
>> That way lies completel insanity.
>
> Oh, do this from time to time.
> Save an object for transport to another DB,
I find it easier to create an empty MDB and import these objects. I
hardly ever need to do this for anything but tables, so the VBE is
not really relevant.
> mass changes to objects,
> control names, and the like, archival purposes, etc.,
What are we talking about here? Ways to use SaveAsText? I use it
occasionally -- had a corrupted form this week after dropping a
subform on it (first time that's happened to me in ages), and
SaveAsText/LoadFromText did the trick. But I don't see much reason
to use the text versions for editing. In regard to mass changes to
controls/objects, I have plenty of choices in that regard already (I
have at least three different add-ins for that purpose, only one of
which cost me any $$$).
> but I also do it to "fix" things like when labels get re-attached
> to the wrong text boxes and such. Sometimes it's just
> easier/faster to do do things outside of Access.
I've never had labels get attached to the wrong items. And if they
did, I'd cut them to the clipboard, and paste them to the selected
control that I wanted them attached to. Why would I need to muck
around outside the Access UI, when it already provides the
capability to attach labels to the correct controls?
> Besides, it's actually kind of fun from time to time!
I have plenty of fun activities outside my actual work.
This discussion reminds me of the people who are constantly
complaining about Access's non-standard join syntax and how it's
such a pain to type all the extra parentheses. My response to that
is that I've never typed a single join parenthesis -- I let the QBE
write those for me!
If you don't want to use Access, use something else. Trying to avoid
the benefits of the QBE and VBE is basically saying you don't really
want to use Access at all.
And if that's the case, you probably shouldn't.
Randy Yates
> This discussion reminds me of the people who are constantly
> complaining about Access's non-standard join syntax and how it's
> such a pain to type all the extra parentheses. My response to that
> is that I've never typed a single join parenthesis -- I let the QBE
> write those for me!
Knock yourself out.
--
Randy Yates % "Watching all the days go by...
Digital Signal Labs % Who are you and who am I?"
mailto://ya...@ieee.org % 'Mission (A World Record)',
http://www.digitalsignallabs.com % *A New World Record*, ELO
Chuck Grimsby
wrote:
> Chuck Grimsby <cgat...@gmail.com> wrote innews:9ffac39e-c81f-4834...@d5g2000yqm.googlegroups.com
Well, to each their own David. I rather doubt either one of us is all-
knowing enough to really talk in absolutes.
I'm not complaining, and I'm not sure how you got that out of my post,
but I can assure you I'm not.
I also know, from our years in this newsgroup, that we each do things
differently. As I mentioned before, I'm one of those guys who likes
to rip the lids off of things to see how they work, and play around
with things ,even when they are things I probably shouldn't be playing
with! (Or perhaps, it's because people say I shouldn't play with
them?)
Anyways, if you like playing in the playground provided, all I can say
is "have fun".
Just know that I (and others) will continue having fun doing things
our own way, even if it's not the "accepted" way.