ACCESS FEED: Oktober 2021

Kamis, 14 Oktober 2021

Re: [MSAccessProfessionals] Docmd.transferspreadsheet help

adding on ,,, ADO has a smaller footprint, and doesn't depend on a current state. For instance, if the data source is being used by an application, DAO might have issues where ADO might not ~

kind regards,
crystal

msaccessgurus.com

On 10/13/2021 1:48 PM, Bill Mosca wrote:

Jim ï¿½ You werenï¿½t alone. All the Access developers were equally confused about the future of DAO. Darn Microsoft!

ï¿½

Regards,
Bill Mosca,
Founder, MS_Access_Professionals

MS Access MVP 2006-2016
My Nothing-to-do-with-Access blog

https://wrmosca.wordpress.com

ï¿½

From: MSAccessProfessionals@groups.io <MSAccessProfessionals@groups.io> On Behalf Of Jim Wagner
Sent: Wednesday, October 13, 2021 10:43 AM
To: MSAccessProfessionals@groups.io
Subject: Re: [MSAccessProfessionals] Docmd.transferspreadsheet help

ï¿½

Bill,

ï¿½

I had just started getting into writing code then. I remember researching code to do something and the examples were all referencing DAO as being old but there were no examples of how to write it in ADO. I was so confused.

ï¿½

Jim Wagner

From: MSAccessProfessionals@groups.io <MSAccessProfessionals@groups.io> on behalf of Bill Mosca <wrmosca@comcast.net>
Sent: Wednesday, October 13, 2021 9:34 AM
To: MSAccessProfessionals@groups.io <MSAccessProfessionals@groups.io>
Subject: Re: [MSAccessProfessionals] Docmd.transferspreadsheet help

ï¿½

Jim

ï¿½

Back in 2000, MS made a big thing over the new ADO code that was supposed to replace DAO. They said DAO was dead and would soon be discontinued. I spent hundreds of hours re-writing several of my applications to do away with DAO and use ADO instead even though DAO still worked just fine. Then Access 2003 came out and MS mysteriously backed away from the claim that DAO was going away. To this day, DAO is the preferred way to work with data unless youï¿½re talking about SOME, repeat, SOME SQL Server stuff. So all my code conversions were for naught.

ï¿½

Moral of the story: Donï¿½t re-write your code unless there is a valid reason. That includes just using different syntax when the old stuff still works. Re-writing code not only is a waste of time. Itï¿½s most likely going to break something. Just because your car is dirty doesnï¿½t mean you need to repaint it.

ï¿½

Regards,

Bill Mosca

ï¿½

From: MSAccessProfessionals@groups.io <MSAccessProfessionals@groups.io> On Behalf Of Jim Wagner
Sent: Wednesday, October 13, 2021 9:23 AM
To: MSAccessProfessionals@groups.io
Subject: Re: [MSAccessProfessionals] Docmd.transferspreadsheet help

ï¿½

Thank Youï¿½Bill. that saved a lot of time rewriting code.

ï¿½

Jim Wagner

From: MSAccessProfessionals@groups.io <MSAccessProfessionals@groups.io> on behalf of Bill Mosca <wrmosca@myself.com>
Sent: Wednesday, October 13, 2021 9:13 AM
To: MSAccessProfessionals@groups.io <MSAccessProfessionals@groups.io>
Subject: Re: [MSAccessProfessionals] Docmd.transferspreadsheet help

ï¿½

On Tue, Oct 12, 2021 at 04:35 PM, Jim Wagner wrote:

Hello all,
I have a lot of vba that transfers spreadsheets into my databases and I have been using docmd.transferspreadsheet acImport, acSpreadsheetTypeExcel12 for a very long time. But now we are getting our data from Alteryx exported to .xlsx files instead of .xls files. I have looked online and there seems to be a bit of a discrepancy between the webpages. could someone help me and direct me to the proper syntax.ï¿½
I did find the below
DoCmd.TransferSpreadsheet acImport, 10, and it works but so does the others.ï¿½
Is there ramifications of having the incorrect syntax?ï¿½

Thank Youï¿½
Jim Wagner

Hi Jim

If your older code works go ahead and use it. The difference between .xls and .xlsx usually only have to do with new features. Transferring data wouldn't change unless you were using some kind of new data type which is unlikely in this circumstance.

MS is pretty good about backwards compatible VBA when it comes to the DoCmd. And Differences in code are sometimes just variations on the same process.
ï¿½
--

Regards,

Bill Mosca, Founder - MS_Access_Professionals

Microsoft Office Access MVP 2010-2016

My nothing-to-do-with-Access blog

http://wrmosca.wordpress.com

ï¿½

Rabu, 13 Oktober 2021

Re: [MSAccessProfessionals] Docmd.transferspreadsheet help

Jim – You weren’t alone. All the Access developers were equally confused about the future of DAO. Darn Microsoft!

Regards,
Bill Mosca,
Founder, MS_Access_Professionals

MS Access MVP 2006-2016
My Nothing-to-do-with-Access blog

https://wrmosca.wordpress.com

From: MSAccessProfessionals@groups.io <MSAccessProfessionals@groups.io> On Behalf Of Jim Wagner
Sent: Wednesday, October 13, 2021 10:43 AM
To: MSAccessProfessionals@groups.io
Subject: Re: [MSAccessProfessionals] Docmd.transferspreadsheet help

Bill,

I had just started getting into writing code then. I remember researching code to do something and the examples were all referencing DAO as being old but there were no examples of how to write it in ADO. I was so confused.

Jim Wagner

From: MSAccessProfessionals@groups.io <MSAccessProfessionals@groups.io> on behalf of Bill Mosca <wrmosca@comcast.net>
Sent: Wednesday, October 13, 2021 9:34 AM
To: MSAccessProfessionals@groups.io <MSAccessProfessionals@groups.io>
Subject: Re: [MSAccessProfessionals] Docmd.transferspreadsheet help

Jim

Back in 2000, MS made a big thing over the new ADO code that was supposed to replace DAO. They said DAO was dead and would soon be discontinued. I spent hundreds of hours re-writing several of my applications to do away with DAO and use ADO instead even though DAO still worked just fine. Then Access 2003 came out and MS mysteriously backed away from the claim that DAO was going away. To this day, DAO is the preferred way to work with data unless you’re talking about SOME, repeat, SOME SQL Server stuff. So all my code conversions were for naught.

Moral of the story: Don’t re-write your code unless there is a valid reason. That includes just using different syntax when the old stuff still works. Re-writing code not only is a waste of time. It’s most likely going to break something. Just because your car is dirty doesn’t mean you need to repaint it.

Regards,

Bill Mosca

From: MSAccessProfessionals@groups.io <MSAccessProfessionals@groups.io> On Behalf Of Jim Wagner
Sent: Wednesday, October 13, 2021 9:23 AM
To: MSAccessProfessionals@groups.io
Subject: Re: [MSAccessProfessionals] Docmd.transferspreadsheet help

Thank You Bill. that saved a lot of time rewriting code.

Jim Wagner

From: MSAccessProfessionals@groups.io <MSAccessProfessionals@groups.io> on behalf of Bill Mosca <wrmosca@myself.com>
Sent: Wednesday, October 13, 2021 9:13 AM
To: MSAccessProfessionals@groups.io <MSAccessProfessionals@groups.io>
Subject: Re: [MSAccessProfessionals] Docmd.transferspreadsheet help

On Tue, Oct 12, 2021 at 04:35 PM, Jim Wagner wrote:

Hello all,
I have a lot of vba that transfers spreadsheets into my databases and I have been using docmd.transferspreadsheet acImport, acSpreadsheetTypeExcel12 for a very long time. But now we are getting our data from Alteryx exported to .xlsx files instead of .xls files. I have looked online and there seems to be a bit of a discrepancy between the webpages. could someone help me and direct me to the proper syntax.
I did find the below
DoCmd.TransferSpreadsheet acImport, 10, and it works but so does the others.
Is there ramifications of having the incorrect syntax?

Thank You
Jim Wagner

Hi Jim

If your older code works go ahead and use it. The difference between .xls and .xlsx usually only have to do with new features. Transferring data wouldn't change unless you were using some kind of new data type which is unlikely in this circumstance.

MS is pretty good about backwards compatible VBA when it comes to the DoCmd. And Differences in code are sometimes just variations on the same process.

--

Regards,

Bill Mosca, Founder - MS_Access_Professionals

Microsoft Office Access MVP 2010-2016

My nothing-to-do-with-Access blog

http://wrmosca.wordpress.com

Re: [MSAccessProfessionals] Docmd.transferspreadsheet help

Bill,

Jim Wagner

Jim

Back in 2000, MS made a big thing over the new ADO code that was supposed to replace DAO. They said DAO was dead and would soon be discontinued. I spent hundreds of hours re-writing several of my applications to do away with DAO and use ADO instead even though DAO still worked just fine. Then Access 2003 came out and MS mysteriously backed away from the claim that DAO was going away. To this day, DAO is the preferred way to work with data unless you're talking about SOME, repeat, SOME SQL Server stuff. So all my code conversions were for naught.

Moral of the story: Don't re-write your code unless there is a valid reason. That includes just using different syntax when the old stuff still works. Re-writing code not only is a waste of time. It's most likely going to break something. Just because your car is dirty doesn't mean you need to repaint it.

Regards,

Bill Mosca

Thank You Bill. that saved a lot of time rewriting code.

Jim Wagner

On Tue, Oct 12, 2021 at 04:35 PM, Jim Wagner wrote:

Hello all,
I have a lot of vba that transfers spreadsheets into my databases and I have been using docmd.transferspreadsheet acImport, acSpreadsheetTypeExcel12 for a very long time. But now we are getting our data from Alteryx exported to .xlsx files instead of .xls files. I have looked online and there seems to be a bit of a discrepancy between the webpages. could someone help me and direct me to the proper syntax.
I did find the below
DoCmd.TransferSpreadsheet acImport, 10, and it works but so does the others.
Is there ramifications of having the incorrect syntax?

Thank You
Jim Wagner

Regards,

Bill Mosca, Founder - MS_Access_Professionals

Microsoft Office Access MVP 2010-2016

My nothing-to-do-with-Access blog

http://wrmosca.wordpress.com

Re: [MSAccessProfessionals] Docmd.transferspreadsheet help

Jim

Regards,

Bill Mosca

Thank You Bill. that saved a lot of time rewriting code.

Jim Wagner

On Tue, Oct 12, 2021 at 04:35 PM, Jim Wagner wrote:

Hello all,
I have a lot of vba that transfers spreadsheets into my databases and I have been using docmd.transferspreadsheet acImport, acSpreadsheetTypeExcel12 for a very long time. But now we are getting our data from Alteryx exported to .xlsx files instead of .xls files. I have looked online and there seems to be a bit of a discrepancy between the webpages. could someone help me and direct me to the proper syntax.
I did find the below
DoCmd.TransferSpreadsheet acImport, 10, and it works but so does the others.
Is there ramifications of having the incorrect syntax?

Thank You
Jim Wagner

Regards,

Bill Mosca, Founder - MS_Access_Professionals

Microsoft Office Access MVP 2010-2016

My nothing-to-do-with-Access blog

http://wrmosca.wordpress.com

Re: [MSAccessProfessionals] Docmd.transferspreadsheet help

Thank You Bill. that saved a lot of time rewriting code.

Jim Wagner

On Tue, Oct 12, 2021 at 04:35 PM, Jim Wagner wrote:

Hello all,
I have a lot of vba that transfers spreadsheets into my databases and I have been using docmd.transferspreadsheet acImport, acSpreadsheetTypeExcel12 for a very long time. But now we are getting our data from Alteryx exported to .xlsx files instead of .xls files. I have looked online and there seems to be a bit of a discrepancy between the webpages. could someone help me and direct me to the proper syntax.
I did find the below
DoCmd.TransferSpreadsheet acImport, 10, and it works but so does the others.
Is there ramifications of having the incorrect syntax?

Thank You
Jim Wagner

Regards,

Bill Mosca, Founder - MS_Access_Professionals

Microsoft Office Access MVP 2010-2016

My nothing-to-do-with-Access blog

http://wrmosca.wordpress.com

Re: [MSAccessProfessionals] Docmd.transferspreadsheet help

On Tue, Oct 12, 2021 at 04:35 PM, Jim Wagner wrote:

Hello all,
I have a lot of vba that transfers spreadsheets into my databases and I have been using docmd.transferspreadsheet acImport, acSpreadsheetTypeExcel12 for a very long time. But now we are getting our data from Alteryx exported to .xlsx files instead of .xls files. I have looked online and there seems to be a bit of a discrepancy between the webpages. could someone help me and direct me to the proper syntax.
I did find the below
DoCmd.TransferSpreadsheet acImport, 10, and it works but so does the others.
Is there ramifications of having the incorrect syntax?

Thank You
Jim Wagner

Regards,

Bill Mosca, Founder - MS_Access_Professionals

Microsoft Office Access MVP 2010-2016

My nothing-to-do-with-Access blog

http://wrmosca.wordpress.com

_._,_._,_

Groups.io Links:

You receive all messages sent to this group.

_._,_._,_

Re: [MSAccessProfessionals] On Load or On Current populate fields on a report for printing

If you have to do data manipulation for records in the detail section, then you might want to use the details section On Print event.

_._,_._,_

Groups.io Links:

You receive all messages sent to this group.

_._,_._,_

Selasa, 12 Oktober 2021

Re: [MSAccessProfessionals] Binary Data in Forms and Reports

hi Norbert,

Add-ins can be tricky to install. I made a reference page to make and install an Add-in here:

http://msaccessgurus.com/tool/Addin_HowTo.htm

Once they're there, though, oh so nice!

kind regards,
crystal

On 10/12/2021 9:56 AM, Bill Mosca wrote:

Hi Duane

ï¿½

ExportAll is an Add-In I created. Itï¿½s on our Files/Utilities folder.

ï¿½

Regards,

Bill Mosca

ï¿½

From: MSAccessProfessionals@groups.io <MSAccessProfessionals@groups.io> On Behalf Of Duane Hookom
Sent: Monday, October 11, 2021 8:36 PM
To: MSAccessProfessionals@groups.io
Subject: Re: [MSAccessProfessionals] Binary Data in Forms and Reports

ï¿½

Hi Norbert,

Where did you get the add-in? I don't believe it gets installed with MS Access. What is the add-in supposed to do? There is a solution atï¿½https://www.devhut.net/2012/09/27/ms-access-vba-export-database-objects-to-another-database/ï¿½

Export MS Access Database Objects to Another Database with VBA | DEVelopers HUT

How-to export MS Access tables, queries, forms, reports, macros, modules into a another database.

www.devhut.net

Duane

ï¿½

From: MSAccessProfessionals@groups.io <MSAccessProfessionals@groups.io> on behalf of drnorbert@gmail.com <drnorbert@gmail.com>
Sent: Monday, October 11, 2021 10:23 PM
To: MSAccessProfessionals@groups.io <MSAccessProfessionals@groups.io>
Subject: Re: [MSAccessProfessionals] Binary Data in Forms and Reports

ï¿½

Bill,

The ExportAll add-in is causing an error ( I am running Access 2019) please let me know what I am doing wrong.

Regards,
Norbert

[MSAccessProfessionals] Docmd.transferspreadsheet help

Hello all,
I have a lot of vba that transfers spreadsheets into my databases and I have been using docmd.transferspreadsheet acImport, acSpreadsheetTypeExcel12 for a very long time. But now we are getting our data from Alteryx exported to .xlsx files instead of .xls files. I have looked online and there seems to be a bit of a discrepancy between the webpages. could someone help me and direct me to the proper syntax.
I did find the below
DoCmd.TransferSpreadsheet acImport, 10, and it works but so does the others.
Is there ramifications of having the incorrect syntax?

Thank You
Jim Wagner

_._,_._,_

Groups.io Links:

You receive all messages sent to this group.

_._,_._,_

Re: [MSAccessProfessionals] On Load or On Current populate fields on a report for printing

Also be aware that the Load() event only fires when the form/report first starts.

The Form_Current() event fires whenever the form has a recordset and the record that has the focus (current record) changes. If the form has a recordset on load, this event fires on startup after Form_Load().

The Form_Current() event does NOT fire when the form starts if the form does NOT have a recordset.

Hope this helps…

From: MSAccessProfessionals@groups.io <MSAccessProfessionals@groups.io> On Behalf Of Paul Baldy
Sent: Tuesday, October 12, 2021 10:46 AM
To: MSAccessProfessionals@groups.io
Subject: Re: [MSAccessProfessionals] On Load or On Current populate fields on a report for printing

If you mean that some records will display one field and others a different one, neither event. You'd use the format event of the detail section (or whatever section contains the controls). Also, nothing is "=" to Null; you'd use the IsNull() function.

Paul

------ Original Message ------

From: "michael simpson via groups.io" <saccity101=yahoo.com@groups.io>

To: "MSAccessProfessionals@groups.io" <MSAccessProfessionals@groups.io>

Sent: 10/12/2021 7:39:59 AM

Subject: [MSAccessProfessionals] On Load or On Current populate fields on a report for printing

Good morning -
Due to personal issues I've not worked on my software for too long...
Hoping to get back on the task...
I've not worked much with reports, and I have never been clear on when to use on load, and on current procedures.

Specifically I have a form that I sent to a report and then print..
Several of the fields may be blank, for example the Warranty Note, 95% of the work orders use a standard note, the remainder will have something other..

If Warranty Note = Null Then
    Standard Note
Else
    Custom Note
End If

Should this be in the On Load or On current event procedure
Take care,
Mike the Plumber
Sac City Plumbing

Re: [MSAccessProfessionals] Binary Data in Forms and Reports

Hi Duane

ExportAll is an Add-In I created. It’s on our Files/Utilities folder.

Regards,

Bill Mosca

From: MSAccessProfessionals@groups.io <MSAccessProfessionals@groups.io> On Behalf Of Duane Hookom
Sent: Monday, October 11, 2021 8:36 PM
To: MSAccessProfessionals@groups.io
Subject: Re: [MSAccessProfessionals] Binary Data in Forms and Reports

Hi Norbert,

Where did you get the add-in? I don't believe it gets installed with MS Access. What is the add-in supposed to do? There is a solution at https://www.devhut.net/2012/09/27/ms-access-vba-export-database-objects-to-another-database/

Export MS Access Database Objects to Another Database with VBA | DEVelopers HUT

How-to export MS Access tables, queries, forms, reports, macros, modules into a another database.

www.devhut.net

Duane

From: MSAccessProfessionals@groups.io <MSAccessProfessionals@groups.io> on behalf of drnorbert@gmail.com <drnorbert@gmail.com>
Sent: Monday, October 11, 2021 10:23 PM
To: MSAccessProfessionals@groups.io <MSAccessProfessionals@groups.io>
Subject: Re: [MSAccessProfessionals] Binary Data in Forms and Reports

Bill,

The ExportAll add-in is causing an error ( I am running Access 2019) please let me know what I am doing wrong.

Regards,
Norbert

Re: [MSAccessProfessionals] Binary Data in Forms and Reports

Norbert

I've found MS has changed security for Access over the years. Open Access as Admin. That should give you permissions to install the Add-in. I'll run a test on my computer with Office 365 installed to make sure it works.

Regards,

Bill Mosca

From: MSAccessProfessionals@groups.io <MSAccessProfessionals@groups.io> On Behalf Of drnorbert@gmail.com
Sent: Monday, October 11, 2021 8:24 PM
To: MSAccessProfessionals@groups.io
Subject: Re: [MSAccessProfessionals] Binary Data in Forms and Reports

Bill,

The ExportAll add-in is causing an error ( I am running Access 2019) please let me know what I am doing wrong.

Regards,
Norbert

Re: [MSAccessProfessionals] On Load or On Current populate fields on a report for printing

Paul

------ Original Message ------

From: "michael simpson via groups.io" <saccity101=yahoo.com@groups.io>

To: "MSAccessProfessionals@groups.io" <MSAccessProfessionals@groups.io>

Sent: 10/12/2021 7:39:59 AM

Subject: [MSAccessProfessionals] On Load or On Current populate fields on a report for printing

Good morning -
Due to personal issues I've not worked on my software for too long...
Hoping to get back on the task...
I've not worked much with reports, and I have never been clear on when to use on load, and on current procedures.

Specifically I have a form that I sent to a report and then print..
Several of the fields may be blank, for example the Warranty Note, 95% of the work orders use a standard note, the remainder will have something other..

If Warranty Note = Null Then
    Standard Note
Else
    Custom Note
End If

Should this be in the On Load or On current event procedure
Take care,
Mike the Plumber
Sac City Plumbing

[MSAccessProfessionals] On Load or On Current populate fields on a report for printing

Good morning -

Due to personal issues I've not worked on my software for too long...

Hoping to get back on the task...

I've not worked much with reports, and I have never been clear on when to use on load, and on current procedures.

Specifically I have a form that I sent to a report and then print..

Several of the fields may be blank, for example the Warranty Note, 95% of the work orders use a standard note, the remainder will have something other..

If Warranty Note = Null Then

Standard Note

Else

Custom Note

End If

Should this be in the On Load or On current event procedure

Take care,

Mike the Plumber

Sac City Plumbing

Senin, 11 Oktober 2021

Re: [MSAccessProfessionals] Binary Data in Forms and Reports

Hi Norbert,

Export MS Access Database Objects to Another Database with VBA | DEVelopers HUT

How-to export MS Access tables, queries, forms, reports, macros, modules into a another database.

www.devhut.net

Duane

Bill,

The ExportAll add-in is causing an error ( I am running Access 2019) please let me know what I am doing wrong.

Regards,
Norbert

Re: [MSAccessProfessionals] Binary Data in Forms and Reports

Bill,

The ExportAll add-in is causing an error ( I am running Access 2019) please let me know what I am doing wrong.

Regards,
Norbert

Jumat, 08 Oktober 2021

[MSAccessProfessionals] Refreshing SharePoint lists with Access 2016

Do you know of a way to programmatically force SharePoint lists to refresh/update? I have multiple users of an Access 2016 database where the tables are stored and shared as SharePoint lists. Lately, following a major SP update at the Company, I have been encountering issues where two users will get different record counts from the same lists. Also, updated fields will appear missing on another users system.

Just wondering if there are any solutions to this situation.

Thank you

Dean Waring

Sent from Mail for Windows

From: Bill Mosca
Sent: Thursday, October 7, 2021 10:58 AM
To: MSAccessProfessionals@groups.io
Subject: Re: [MSAccessProfessionals] Binary Data in Forms and Reports

Hi Norbert

You shouldn't be deleting the binary code in Access objects. It is needed to make the objects work. Deleting the wrong stuff could break your objects. Exporting into a new, blank database will remove all the unnecessary code such as the blocks for deleted controls.

The ExportAll add-in is in https://groups.io/g/MSAccessProfessionals/files/0_Utilities%20and%20Add-ins Be sure to read the ReadMe file so you extract the add-in to the right folder. Add-ins have pre-determined folder paths in their tables.

Regards,

Bill Mosca

From: MSAccessProfessionals@groups.io <MSAccessProfessionals@groups.io> On Behalf Of drnorbert@gmail.com
Sent: Thursday, October 7, 2021 6:26 AM
To: MSAccessProfessionals@groups.io
Subject: Re: [MSAccessProfessionals] Binary Data in Forms and Reports

Thanks, Bill, for the great explanation.

Are you aware of how the creation of unnecessary binary data can be eliminated?

You are correct when I export the form or report and delete the Binary Data and import again remain it shrinks, however when I make a change and repeat the export process the Binary Data is recreated.
I always keep watching the bloating of the program as well.

Can you share please Is your ExportAll utility?

Regards,
Norbert

Kamis, 07 Oktober 2021

Re: [MSAccessProfessionals] Binary Data in Forms and Reports

Hi Norbert

Regards,

Bill Mosca

Re: [MSAccessProfessionals] Binary Data in Forms and Reports

_._,_._,_

Groups.io Links:

You receive all messages sent to this group.

_._,_._,_

Selasa, 05 Oktober 2021

Re: [MSAccessProfessionals] Binary Data in Forms and Reports

Norbert

If I may jump in to add my two cents...Forms and reports are objects in Access. As with all Access objects, when an object is created it is built using code. Much of that code is a template that holds places for various items (controls) in that object. The code is then rendered into a viewable item. To present a form or report, the compiler compiles the code that makes up the object.

One thing that many Access users don't realize is that if you put a control on a form and later delete that control the code for it remains in the form's metadata. This eventually leads to all kinds of bloat. I long ago got into the habit of keeping an eye on the file size of any Access project I was developing. When the size became unreasonable I simply imported everything into a new, blank database. That strips out all that useless code and brings the file size back down to a reasonable size. That process also strips out all the unseen garbage in the code pages and boosts performance.

I created a utility called ExportAll for this very purpose.

On Mon, Oct 4, 2021 at 02:00 PM, <drnorbert@gmail.com> wrote:

Dear Crystal,
Sorry, you are correct I meant 1999, the inception of Access version 1.0 was on 11/ 1992.

I am still puzzled about what creates the Binary Data in forms and reports even though they don't have an image included.

Regards,

Norbert

Regards,

Bill Mosca, Founder - MS_Access_Professionals

Microsoft Office Access MVP 2010-2016

My nothing-to-do-with-Access blog

http://wrmosca.wordpress.com

_._,_._,_

Groups.io Links:

You receive all messages sent to this group.

_._,_._,_

Senin, 04 Oktober 2021

Re: [MSAccessProfessionals] Binary Data in Forms and Reports

hi Norbert,

perhaps compiled code is one of those ... who knows ... undocumented! As you figure things out, share back!

When you reply, please look and "include previousï¿½ messages", "Quote Post" or something like that so we can see the whole thread, thanks

Quote Post .. Duane uploaded an image here:

https://groups.io/g/MSAccessProfessionals/photofromactivity?id=2977001

kind regards,
crystal

================

On 10/4/2021 4:00 PM, drnorb wrote:

Dear Crystal,
Sorry, you are correct I meant 1999, the inception of Access version 1.0 was on 11/ 1992.

I am still puzzled about what creates the Binary Data in forms and reports even though they don't have an image included.

Regards,

Norbert

On 10/3/2021 12:30 PM, crystal (strive4peace) via groups.io wrote:

hi Norbert,

Thanks! AutoCorrect is a big culprit. It would be nice to have a list :)

1989 was before Access -- aï¿½ long time ago though ~ I made that note in 2010.

kind regards,
crystal

ï¿½

~ remote training and programming ~

connect to me, let's do it together

On 10/3/2021 11:47 AM, drnorbert@gmail.com wrote:

Hi Crystal,

Wonderful to hear from you.
You are correct, John suggested to me in 1989.
The issue with the reports and forms is that they tend to bloat.
I want to find out what creates the binary data in a form and report.
I delete all the binary data and the form size reduces to almost half.
Let me know if you are familiar with this issue.

Regards,

Norbert

On 10/3/2021 9:36 AM, crystal (strive4peace) via groups.io wrote:

hi Norbert,

thanks for sharing.

The text files created by SaveAsText are undocumented, and indeed interesting. Several years ago, John Viescas said to "Delete everthing between NameMap = Begin and the matching End statement and save the file." for cleaning up what AutoCorrect does.

kind regards,
crystal

Document Access Tables to Excel
https://www.youtube.com/watch?v=r6LRurruI44

On 10/3/2021 8:20 AM, drnorbert2002 wrote:

How and when the binary data is created in forms and reports?

ï¿½

I use the two undocumented functions. Application.SaveAsText and Application.LoadFromText ï¿½functions to export the form/report definitions, identify the binary data blocks and

I clean up the definition, and then import it again.

The Binary Data Blocks starts in ï¿½Parameter = Beginï¿½ and ends with ï¿½Endï¿½.

Also the I delete the ï¿½Checksum=ï¿½ line. (should be on line 3)

The data blocks are in the following parameters.

NameMap

PrtMip

PrtDevMode

PrtDevNames

PrtDevModeW

PrtDevNamesW

Thanks,

ï¿½

Norbert

ï¿½

Norbert Foigelman, Ph.D.

NSF Services Corp.

Newport Beach, CA