Recent content by chacham

I received error 13146 (see other thread) consistently. The message is: Sorry, an unexpected error occurred Please exit and restart <database title>. In my case, it was from trying to embed a non-embeddable type. I'm guessing 13146 is a general OLE error.

Okay, someone answered the problem for me elsewhere. Png is not an embeddable type, hence acOLECreateEmbed is the wrong action, and instead should be linked via acOLECreateLink.

Converting an attachment field to an OLE column (in a child table) via code works fine unless the attachment is png. Sub b(Table As String, PK As String, Column As String, Form As String, FK As String, Field As String) Dim Recordset As DAO.Recordset2 Dim Attachments As...

It was a simple example to illustrate the point and get the conversation going. :) I assume you mean not a surrogate id. Unfortunately, many people would use an id. I have seen this over and over again. Worse, some people teach it this way. I got bit by that once was we needed to add a...

That is negligible. Processing time is at worst nanoseconds. I remember reading this in a blog who explained this in great detail (was it Richard Foote?). There is basically no point in using a surrogate key for space or speed in most cases. If there ever was such a time, it was decades ago...

Interesting. I used .ExecuteNonQuery(). .Execute() is not a member of OleDbCommand. I feel like the exact opposite is true. Perhaps we an chalk that up to different experience. I feel like it makes them simpler. It is so much easier to follow joins when the columns that make the join are there...

Why not? Personally, i think they make excellent PKs and i always use them. Could be. Fwiw, i read your comment of not using a composite PK as being explained with "if you need to join your table to another table, that other table will also need all three fields." To that i responded that is...

Why be afraid of composite keys? :) I almost never use surrogate keys. Aside from being redundant, they usually end up being confusing and problematic. In any case, this is a staging table, so, there shouldn't be any FKs on it.

There's a difference? I'm not terribly familiar with Access. I added a PK because i wanted it indexed and guaranteed unique, which is what a PK is.

It's stylistic. I am not a fan of exception coding. Also, when i tried it, VB reported an error due to the duplicates. Assuming there are no other processes modifying the data. It's not guaranteed, but it usually works.

It took me way too long to figure out a solution. I can use the table being inserted into as a guaranteed table the program has access to, and select count(*) to guarantee exactly one record: INSERT INTO Staging(Last_Name, First_Name, Birthdate) SELECT ?, ?, ? FROM (SELECT COUNT(*) FROM...

I did indeed add a primary index to the staging table on all three columns. I don't like the idea of silently dropping errors (already on index) unless that's the only way. The question marks are oledb parameters. The query object itself replaces them with the appropriate values when running...

I am using VB to pull some names from a PDF document and write them to the database where they do not yet exist. The query itself is: INSERT INTO Staging(Last_Name, First_Name, Birthdate) VALUES(?, ?, ?) The parameters are added and the query prepared. This works. Now i want to change it to...

Thank you! Works perfectly.

Thank you. I already wrote a migration routine to transfer the data, and used a child table to hold the attachments. The routine works nicely, though it took a few tries to get the attachment field to be converted for transfer. Too bad that process was put on hold for the time being.