Search results

So you ran the repair on MS Access since it is separate from the rest of Office?

Try going to Control Panel \ Programs \ select MS Office and do a repair on it. Doing so with Office Pro 2010 successfully repaired a workstation with corrupted MDAC installation.

Quite the contrary... clarative, not disappointing in the least.

Oh, that type of syntax is where your thoughts were going. Thank you for explaining.

I did a slight-of-hands workaround... Sort by: vendortitle Group on: vendorid Sort by: partnumberIn SQL RDBMS's, GROUP BY does absolutely no ORDER BY behavior. So just having a GROUP BY in a query provides context for GROUP based functions, like perhaps a SUM. A separate ORDER BY clause...

It might indeed be. I had never seen such syntax. BE for my ERP / BI system is SQL Server 2008. The production ERP runs on an iSeries, thus DB2/400. I am only allowed ODBC connections to both servers. The servers themselves are IT controlled. I have no access to any SS*S services to use with...

I am suspicious that in Access, Reports Group On behaves differently than in SQL RDBMS's. I have an Access Report which in the "Group, Sort, and Total" pane has the following: Group on: vendorid Sort by: vendortitle Sort by: partnumberI was expecting the first to simply group all of the...

In Group By fields in Reports, I have successfully used this to test for a completely empty report to prevent an error message: =IIf([Report].[HasData],[statuscode],"N/A") In the case there report has no data to display, "N/A" shows up in the Group By field.

I solve this type of challenge in real SQL RDBMS's via casting the numeric data as a VARCHAR, then performing the LIKE comparison. Example: WHERE VARCHAR(UDISPUNTCST) LIKE '%.___%'To select rows with greater than two decimal places of precision.

Access does not seem to be appreciating such syntax as you suggested. I have not found mention of such syntax being supported. Could you please provide some references?

No, do not delete. Just call that code in your application start-up to update the connection strings of the DAO Linked Table objects. I repete, DO NOT delete the DAO Linked Table objects... merely edit the connection string contained within them.

Give this solution a try... Linked Table Saved Password ADOX code http://www.access-programmers.co.uk/forums/showthread.php?t=226468#post1155700

Intriguing technique. I had never seen the "(myConnectionString).mySQLTable" type syntax before. So by using that, you think it is possible to avoid Linked Tables altogether? And I have successfully working DAO connection strings as I use a nested DAO.QueryDef technique to download records...

Say, that is right... I could develop the query in an adoCMD object since both tables would be considered local to the Access FE DB. ;) How would you execute a query to directly transfer between Access --> SQL without using linked tables? If not linked tables, then in my mind one is left with a...

Greetings, I am hesitantly considering use of a non-Pass-Through query to bulk populate SQL Server tables. All other areas of BE DB SQL access are via Stored Procedures (SP's). To publish records from Access to SQL Server, presently I fire an INSERT SP for each record to be populated to SQL...

You are most welcome, Tony.

Have you seen: For Each accObj In CurrentProject.AllForms strDoc = accObj.Name bWasOpen = accObj.IsLoaded If Not bWasOpen Then DoCmd.OpenForm strDoc, acDesign, WindowMode:=acHidden End If If Forms(strDoc).HasModule Then...

I have forced changes back into the table where I have editable forms bound to tables. On each editable field control I have: Private Sub addpartrecordflg_AfterUpdate() 'This will force the UI change back into the table If Me.Dirty Then Me.Dirty = False End If End SubIt seems like...

I started receiving random 3021's when I switched my Multiple Item / Continuous Forms to not show a blank row when no data was populating the form. Since such forms in my applications are read-only, there is no point in displaying a new record row which they will never be allowed to enter data...

I was able to translate what I had working against the local Access FE DB and have the same code scheme execute a Stored Procedure. I also found that I could simplify the code slightly, doing all of the work in the Form Open event, and no longer need the additional Form Load event. Option...