Search results

Hmm, that's very interesting observation. That would actually suck if that's something true of any ActiveX control and not just FlexGrid. I guess it makes sense since ActiveX control have to be persisted but to think that copying then changing properties would create that amount of bloat is...

I see. Did you use the code as it is? On the form or on the query? I can't say I've gotten two files, a XLS and a XML. I've found it more convenient for the users to just open it in Excel and let them handle the save operation, which is why I omit the filename parameter and use...

Why not simply export directly from pivottable itself? (assuming code is in the module behind the form) Me.PivotTable.Export , plExportActionOpenInExcel Reference

Here's what I did to "trace" the bloating. Create a new form, put one textbox and set Popup=yes. Clear out all other properties (Record Selector, Navigator etc etc) so it's more like a dialog. Set an timer interval of 1 and add an timer event: Me.Text0 = FileLen(CurrentDb.Name) When you open...

I've traced it to simply opening the frmParts. However, I had problem with tinkering with the frmParts. For starters, I got an error: 438 Object doesn't support this property or method on this line: Forms!frmParts!LstFlxGrd.Redraw = False for the procedure FillLstGrid. Furthermore, if I...

I don't see a link? Have you tried zipping it up?

One thing to consider is that if you are on a 64-bit OS, you need to be sure you're using 32-bit regasm and not 64-bit regasm. 32-bit regasm: C:\Windows\Microsoft.NET\Framework\v2.0.5727\regasm.exe 64-bit regasm: (the only time you would use this is with 64-bit Access 2010. Otherwise, don't...

I would much strongly recommend that you do not open database on a network share. Instead, split the database and give users their copies of the front-end. This is considered a best practice since Access' inception. I don't know why it's now an issue with 2010 when it wasn't with 2003, but...

You'll need to provide an example of what you're describing because AFAIK the behavior of Database.Execute & Database.OpenRecordset and DoCmd.RunSQL & DoCmd.OpenQuery is pretty much consistent once you take in the differences of how they resolves the references to Access objects.

There's this e-book.

I see that you've commented out the CreateQueryDef & QueryDefs.Delete. That would have definitely created bloating. If there's still other like that, you'll want to comment that, too. It's OK to change SQL property of an existing QueryDef, but generally avoid CreateQueryDef. DAO does have a qry...

I do not believe using dynamic SQL, whether via Database.Execute or DoCmd.RunSQL method create the bloat. It's mainly related to creating objects because by design, when Access needs more storage to hold data (whether temporary or not), it allocate the extra space on drive but when it's done...

Are you creating any temp tables? Creating any controls/forms/reports at runtime?

I would think that because you're referencing DAO 3.6, it is not able to recognize the newer ACCDB file format. Either use a MDB file format or reference instead "Access database engine object nn.n object library", where nn.n would be 14.0 for Access 2010 or 12 for 2007. Note that this is still...

First, when you get a "ODBC-call failed", this is merely a generic error and to find out the specific errors, you need to enumerate all of errors in the DAO.Errors collection. Second, have a look at Doug Steele's DSN-less connection sample.

Right - whether it's month names or month numbers, you don't want to "repeat" the column that would contain same kind of data but differs only in attributes (e.g. the motnh this data is for). That's why you want a column "BudgetMonth" to identify which month this budget is for. Same thing with...

Caveat: I tend don't download files so my answer is based on the post and apologies if this is off... If you mean that your table has this ... Jan | Feb | Mar | Apr | .... | Dec then this isn't the best way to design the table. This is definitely useful format as a *report* but not for the...

The part about "Par1" and "Par2" concerns me somehow as this suggests that the table may not normalized. If Par1 and Par2 are fundamentally same measures that happens to measure a different aspect (e.g. length and width as example), then it may make more sense to split those column into their...

You got the right idea, but I think you only need this: DataLoggerLocationSWN for your child field links. Brackets are object identifiers and only required when you have a name that has characters that would be ambiguous. An example is when you have a table named "My Table", spaces makes it...

IMNSHO, there's no point in using a calculated field for Access 2010 database if it's not going to be used in web. This feature was given as addressing issues associated with deploying a web database. Frankly, the whole thing is questionable because for starter, you can't index it. At least in...