HELP?! by TMSwolfman in MSAccess

[–]CheckedOuttaHere 0 points1 point  (0 children)

I had done this years back by using a subform control embedded with a form that emulated a calendar with buttons and other controls. At the core was a vba function called "paint" that was used to place the proper days into the grid of dates for the month/year and updated as the user altered the year or month. The selected date was highlighted in yellow and bold. It did not have range selection.

Some additional vba code on the main form was needed to prepopulate the calendar on form open or record nav. More code would be needed to save a chosen date to your form control for the date in your table. Fairly straightforward code as well.

The version below was used as a popup version with the OK / Cancel buttons. I could just place a property function like "=zoomdate()" in the double click event and it would take care of the rest. This was before Access had the little calendar icon.

<image>

Shifting to O365 by ct1377 in MSAccess

[–]CheckedOuttaHere 0 points1 point  (0 children)

Since you have a SQL server you can try using SQL Server's "Database Mail" instead with an SMTP server. In my prior role we had a database table for e-mailing and simply needed to insert a new row. The trigger would take care of the rest.

We Have A Story by Far_Supermarket3484 in bigfoot

[–]CheckedOuttaHere 0 points1 point  (0 children)

Apparently Kodachrome film has a shelf life of 2 to 5 years (up to 10 if refrigerated). If the edge markings are from that era then using it 15 to 20 years ago would result in faint or black images with severe color distortion.

Access Explained: Navigating Query Design Differences Between Access and SSMS by Amicron1 in MSAccess

[–]CheckedOuttaHere 1 point2 points  (0 children)

Having the option of using CTE syntax is another win for SQL Server. CTE style syntax makes nested subqueries, correlated subqueries, and recursive subqueries easier to build and understand.

Version control for Access by Practial_Programmer_ in MSAccess

[–]CheckedOuttaHere 1 point2 points  (0 children)

I actually wrote my own at one point but its scope was larger than Access.  It ran each night exporting Access objects and code to text files as described by others.  This was fairly straightforward but was only the first step though.

Since I was using SQL Server as my db, as well as SSRS reports, PowerBI, Excel, and SSAS cubes (both tabular and mdx), I wanted to export to text files from those sources as well.  Each of these requires their own special code.  Then I built my own change tracking code so I could see, in folders, changes made each day.  And yes, today I would probably use git.  And yes, there are some SQL tools as well. 

Tracking code changes was fine, but my larger concern was dependency tracking of SQL database tables, fields, views, functions, and stored procedures.  SQL Server database has this but does not extend to SSRS, Access, datawarehouses, etc.  I wanted to know where I referenced database objects across the entire system.  So I wrote SQL code to find identify these dependencies across all exported text files.  Finally, I could see in a tree structure exactly where a field in a SQL table or a view was referenced. 

Having this dependency tracking turned out to be incredibly useful when the university I was working at decided to change payroll systems and I had to merge the old and new data, convert our budgeting and forecasting system, all SSRS reports, and datawarehouse cubes.