Search results

I'm pretty sure you will need to convert the integer to a string, and then compare.

How abut just letting the user select a row in the subform, and use it's primary key to issue a SQL DELETE statement with code like this behind a cmdbutton: dim i as integer dim sSQL as string i = subform_record_primarykey sSQL = "DELETE FROM SubFormTableName WHERE ID = " & i DoCmd.RunSQL sSQL

Avoid the issue entirly. Don't persist derived/calculated values like the cost of raw materials. Instead, calculate them on the fly in a query as needed. The last thing you want to do is multiply the cost of a part by the quantity estimated for the job and store that. This design can never...

Gosh, why not just pay the $7.00 a month for someone else to host it? There are plenty of places that will host your SQL Server DB in that ballpark.

Yes, MERGE was created just for this type of work.

Also, the learning curve for creating SSIS packages is even steeper, and without a deep understanding of T-SQL, views, stored procedures, and SQL Server in general is probably insurmountable, so scratch that approach for now.

Stored procedure is the way to go. You will need to buy a SQL Server book and learn how to use it unless you have a DBA who can handle the back end for you.

You are right, you don't need Enterprise edition. I put my customers on Standard edition. I need SSIS packages to be scheduled to run on their own and also want backups to run unattended. Standard edition is relatively cheap.

The way I did this was to fabricate an ADO recordset, and included a bit (yes/no) column. Then when the user has checked whatever records he wants, have a command button to make a pass through the fabricated recordset and call an insert routine for each checked row.

For a couple of reasons. First, if the data used to calculate a total, for example, changes, there must be code in place to detect that, recalculate the data and persist the new total. Second, its wasteful of space. Compare that to doing the calculation in a query. The calculation is made each...

This is all quite vexing. One bit of low hanging fruit I can think of is this: Change this code to look like this, and then post what sWhere is literally: Private Sub OpenLocalUsers_Click() Dim sWHERE As String sWHERE = "[Computer]= '" & Me.Computer & "'" msgbox sWhere ''<---------...

Assuming the records have unique ID's, and the form exposes which records are checked so you can loop through and get the ID's, SQL like this will do it: UPDATE tablename SET commentcolumn = commentvariable WHERE ID IN(1,3,5) A more elegant solution would be to temporarily save the checked...

It's a database best practice not to store calculated or derived data. The correct approach is to create a query that calculates the percentages. That query will do what you are trying to accomplish - eliminate the physical steps.

If it were me, I'd scrap that table design, design a normalized structure, move the data into it and redo the report. Then you'd have a Locations table that was properly indexed, and you could much more easily write a faster performing report. Almost certainly the other 90 columns in the Project...

I think I'll post as I see fit, not as you think I should. Do you moderate this forum?

I ought not have to have to provide a mechanism to a competent developer to allow them to decide which records in their database need to be put to Excel, and I won't bother with that. Bear in mind I am a SQL Server developer with a lot of experience as a Visual Basic 5 and 6 developer. I have...

These are very valid concerns. When I started using SQL Server, I already had lots of experience with huge server based databases, and the learning curve was still steep. Took me a couple of months to get up to speed. No SQL Server database can safely exist, be backed up, have physical design...

Glad I could help, Sophia

Here's code to execute a parameterized stored procedure. This one just does work on the backend, but you could just assign the output of the procedure to a recordset. This code lives in a class, so the paramters (iAthleteID, iTmp) are set as properties of the class object. Public Sub...

Without spending the time in the database to understand the implementation of that business rule, which I don't have time to do, my opinion on how to know how many and what recordsets to create isn't valid. Presumably the developer knows their business rules. Here's code to put recordset(s) to...