Search results

We support in excess of 40 databases of various sizes that are hosted in Azure SQL with Access front ends. Whist it will never be as quick as a local SQL backend, if it is carefully designed the "slowness" is minimal, and with sensible planning can out perform a local Access backend...

Azure has a cost but it varies tremendously depending on what you set up. ~£50 a month gets you a scalable, resilient Cloud based SQL server for a basic system, with redundancy and backups. I don't think that's a lot. ~£200 a month gets you something you could run most medium/larger sized...

If any of the destination and source tables have an Identity (Autonumber) field it would fail, however I would expect it to tell you that as the error message, not one about MV fields?

If the fields being updated are indexed then the index also needs updating, which when it involves millions of records can take a considerable amount of extra time. When doing enormous updates it can be beneficial to drop, update, and then recreate the indexes.

If you simply set the control default value to Date it will only apply to new records, unless there is something more complicated going on here.

Try the following Forms!Form0_AddEditJob!TBOX_DateInitial.DefaultValue = "= Date() "

If you are doing this dynamically on a continuous form (e.g. up/down arrows for example), you only ever need to move the item up or down one position, so you only need to adjust the previous or next item in the list and replace their sort order with the original. It makes it much simpler.

You can use a "empty" parameter query and simply define the SQL as you go. No need to hard code it. You could in fact store the SQL strings in a table and use string manipulation to replace holders for the criteria operators? That would make the queries themselves data driven. Whether it is...

No you can't. Consider this SELECT Blobby From TABLE1 Where CNum > [@YourParameterValue] Against SELECT Blobby From TABLE1 Where CNum "> [@YourParameterValue]" Can you see why it won't work? It doesn't understand the second one, as it's not a valid SQL statement.

Your query def should be > [SortOrderCriteria] You can't bodge the ">" into the parameter - it's declared as a long, and wouldn't work as a string. So in the query simply place the > in front of the parameter holder and save it.

It can be very useful for simple things to avoid creating them in a query. One of the best examples would be concatenating FirstName and LastName fields into a calculated FullName field , also Initials , as they are frequently used.

In your source queries try the following Eval([Forms]![PowerBI_Export_Pop_Up_Form]![Text2]) and see if they suddenly work.

The parameterised query is by far the best way to handle potential character issues. Imagine passing in a password - something like d£t%"_ u|?''p5= The parameterised query handles it seamlessly. Replacing things would almost certainly fail to handle this in most cases, and obscures what is...

I have assumed it's an Excel Table not a linked table, and I'm sure the same applies when using formulas. There is no such thing as a Null value as far as Excel formulas are concerned. It doesn't have an intrinsic IsNull formula operator. A null cell may have a formula in it bizzarely...More...

You must set the form border style to dialog, not NONE.

@Pat Hartman - In an Excel cell formula there is no NULL only ever "" when a cell is empty.

2. Set the border style to Dialog. Open it as acDialog , set control box to no, close button to no. Remove the caption.

Just to confuse or conflate matters, I had this happen to me ages ago, on Windows 10 - A rogue Access process left behind, after closing a database either manually or in code. I never got to the bottom of it (tried office repair, remove and reinstall etc. etc. ). I only made it go away when I...

Because the backend is SQL server and your Server table field didn't allow nulls, Access doesn't know about that until it's too late. Table level validation is a pain to use with anything other than an Access table, as Access doesn't apply the rules, the server does. Table level constraints...

You could host the BE Database in Azure SQL Server and maintain your current front end Access application, with suitable modification to allow for the performance difference between the WAN environment and the current LAN set up. I suspect you would need to move quite a lot of the processing...