Search results

The index will indeed make the biggest impact, alternative is to make a (dummy) table and mass update once... Or use an intermediary table to copy the records into... the full table scan (without the index) is hurting you ... doing 105 full table scans. Though by their nature Indexes perform...

In your query , form or report where ever you need this.

Using a linked table is the main source of performance trouble as well as going over the connection 100 times. Create a pass through query: Yourquery uSQL = "" For i = 1 To TrayQty uSQL = uSQL & "UPDATE [Element Weighing] SET " & _ "[Final Melts By] = '" & Me.[Operator].Value...

IIRC there are properties on the form that you can set to fill the entire screen.

your date is being stored inside the database and the default format setting of the date field is US date format. If you want to have a different date format, you have to apply said format to your display(s) either on table design level or on form/report level.

SELECT DISTINCT Main.Dt, Main.dt + 1 Missing_Dt FROM Main left join Main Main2 on main.dt + 1 = main2.dt where main2.dt is null ORDER BY Main.Dt ASC ; only issue here can be 2 missing dates in a row or multiple

KISS wtf

Null is always a pain to deal with, how about forcing such columns as Status to be atleast autofilled to some default status... No null values, no null value related issues.

Best solution is to NOT delete records period... you can only delete a record once, and in all cases you are destroying potentially precious information. The solution is to have a field "DELETED_YN" or "Deleted date/time" or simular and fill that when the record should be deleted. This also...

Be casefull with these where clauses, as you are breaking any possibility for the database to use an index... not using indexes can cause serious performance issues over time You will be better of using something like: Where Yourdate between dateserial(year(now()), month(now()), 1) and...

4 dcounts, that is 4 seperate queries... from a performance point of view a bad situation. Instead you are better off running just one query and perhaps even binding that query to your form to display... this will perform significantly better.... Overall any D function is a bad idea and a bad...

The import export manager is bugged; if you run it enough times eventually it will fail ... fortunately the workaround is easy, restart the database but its painfull. If you want a guaranteed working solution which is faster to boot, research "open"-ing a file manually and processing it from there.

You cannot refer to a form field from within an openrecordset statement. Try one of the following: Assuming CNo is a number: WHERE T_JobOffer.CNO = " & Forms!F_EOSB!CNo) Assuming CNo is a string: WHERE T_JobOffer.CNO = """ & Forms!F_EOSB!CNo & """") Assuming CNo is a date: WHERE...

Use a query as per the suggestion of @theDBguy suggested. ps. I realize it is only your first four columns, but where is your PK? It is customary to have this as your first column.

Glad you got it working, happy to help :)

given the way the pivots work, your only solution is to build the crosstabs in vba but.... that means adjusting the forms too.... which is not "desirable" Best way around this is to fix the columns in the crosstab by using Sunday, monday etc... as column names. Then in the form use those...

If it works in a blank database; this is your problem :(

Highly possible that you have a module someplace that is not compilable. I.e. it has some coding problem.... try compiling your modules to see if this is the problem.

A lot of stuff going on there, only a small part about what you are talking about. Seems like a long and wrong way to get from A to B by way of E, but as long as you have a working solution good for you :)

No maybe about it, this is a pivot table.... though 88 columns is somthing of a pivot table.