Search results

Yes to both.

What you are doing is correct IMO. In the case where I am storing concatenated lastname and firstname, it makes sense. It's a core business object in our app, referenced all over the place, and I think it would end up being less efficient to be forever writing code to do the concatenation on...

Good question. Triggers run on the database server, in response to INSERTS, UPDATES, DELETES (actually a little more granualar). Since they run on the DB server rather than the client, they are much more efficient than, for example, VBA code in an AfterInsert event in Access. And they are...

Full disclosure: I was a SQL Server DBA long before I turned to Access as a development tool. I love Access as a RAD tool against SQL Server. If reliability and uptime in a multi-user environment are what you need, move to SQL Server. I have had SQL Server database with 100% 24/7 uptime for...

I use this code to completely hide the nav pane: DoCmd.NavigateTo "acNavigationCategoryObjectType" DoCmd.RunCommand acCmdWindowHide And this to un-hide it: DoCmd.SelectObject acTable, "MSysObjects", True

I would stop right here, buy a book on using MS Access, and learn VBA. If you have never written any VB code, it's going to be hard to communicate how to do things.

You can do it in one INSERT statement, like this. First, get the InvoiceID and put in a variable, iInvoiceID int. Then make a SQL Statement like this: "INSERT InvoiceItem (InvoiceID, Items, ProcePerItem, Quantity, TotalPerItem) SELECT " & iInvoiceID & ", Items, ProcePerItem, Quantity...

I have the same dilemma. I'm storing images using an attachment column. It's in a separate Access database, and the person records are in SQL Server. All that works fine, and by sizing the attachment control appropriately, it works to display the person's head shot. My experience is that...

I do this all the time. The challenge is to bring the data into tables that, if properly designed, are related by ID columns, as I know yours are. So, as the data go into the tables, new IDs are incremented. Usually, you have to create am updateable query that does a JOIN on literal values...

http://www.connectionstrings.com/sql-server-2008 http://msdn.microsoft.com/en-us/library/ms177523.aspx Bear in mind if you are using SQL Server, the best way to update a record is through a stored procedure, IMO. That way the database work happens in the database engine.

freevbcode.com for lots of good, usable code. vbforums.com. Just like here, only VB. There's lot's of advice one could give about writing good VB6/VBA code. The most important, in my opinion, is use classes to modularize your code and de-couple code from forms.

There can be performance issues, but not directly because of linking. My SQL Server is half a continent away, but the performance is fine. My developers are on a different continent, as are my users, and performance is fine. Performance can be impacted by network/internet speed. All that aside...

Glad to help. If you want a query to be updatable, in the case of using it on a forn, there are conditions it has to meet. I know them in SQL Server, but if you ever bind a query to a form and it won't allow update, you are probably missing a primary key from one of the tables. Just saying for...

99% of the time, it is wrong to store a derived or calculated data in a table. Use a query. You can treat the query as a table, using it as a datasource for your reports, forms, etc.

Then there are Data Macros in Access 2010 that look interesting. http://blogs.office.com/b/microsoft-access/archive/2009/08/13/access-2010-data-macros-similar-to-triggers.aspx

vbaInet is right. However, in the case of concatenating a name, depending on your app, it can be a good idea. I do just this in my commercial app, because the lastname, firstname is how the users think about the 30 or so people that the deal with. That said, I use SQL Server as the BE, so it's...

Good link. I was very lucky to work with pretty brilliant SQL Server developers early on, and they taught me a lot. Set-based thinking is sometimes easy, like in this simple INSERT case, and can be much much harder. I'm grateful to the folks I learned from.

Assuming you are storing the foreign key from the lookup table, and your SQL Server tables are linked, it's no different that doing the same thing with local tables. Set control source, row source, row source type, and bound column properties, either manually or throught the control wizard.

INSERT statements need to have columns on both sides balance. So, it's fine to use a SELECT as the right side, but you have to remove the *, and it should work. As an aside, I use this SELECT technique to insert multiple rows with a single INSERT statement, by selecting against a control table.

Very Nice!