Search results

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.

1. Thank you for the advice. Unfortunately, its not my database. I'm just helping with some of the code. Fwiw, eventually, we should be moving to SQL Server. 2. Ooh. I'm checking that out right now.

I was asked to add a button that opens another form based on the current record. No problem. I just copied the button and code from another form that did the same thing. The user came back to tell me that the entire purpose of opening that second form was to click a button that opens the...

To answer my own question, though i do not know if it is best, i added a another query to query the form's query: SELECT COUNT(*) AS Total FROM (SELECT DISTINCT <Name> FROM <First Query> WHERE <Checkbox> = 0); The textbox then uses DlookUp(): =DLookUp("Total","<Second Query>")

It's better to use isnull(x) over just plain x is null?

A form lists names with some data and three checkboxes. I've been asked to add totals to the footer for each of the checkbox columns. 2 of them are to display total unchecked for records that have a date. (It is not supposed to be able to be checked if there is no date.) The third checkbox is to...