Search results

Declare an access application object then set it = to the remote database. Set appACC= getobject("PathToFile") Then use the references method of the application object, that might work.

Look into the Application.References object then, the issue you may run into though is if your code won't compile then it may not run to be able to update the references.

You should look into Late Binding objects for production releases, it will avoid the reference issues you're running into.

You cannot assign variables in this way, the better question might be why would you want to? You can store all the values in an integer array and just use that, or if you need to cross reference stings and integers look at using a collection or dictionary object.

strContents = replace(strContents ,vbCr,"") or perhaps strContents = replace(strContents ,vbCrLf,"") if you have line feeds as well

Tables can't accept formulas and aren't supposed to, they are used to store data. You could look at creating that formula as a query to append or update records.

Well what kind of errors, specifically, are you getting in the runtime version vs the full version?

Well dbSeeChanges is an Option "Set recordset = object.OpenRecordset (source, type, options, lockedits)" So try... OpenRecordset(SQL,,dbSeeChanges)

Unless you have a specific need to use Excel Automation (creating pivots, formatting, etc...) I would suggest using the TransferSpreadsheet method of DoCmd.

You are correct so far as VBA is concerned, variables are just pointers to where the data is stored in your computer's memory, so it is not shared across instances. If you were using database properties, or tables to store variable information then that would be shared. I will throw my two...

You can use an ADO Stream object to convert between UTF-8 encoding and unicode. Sub StreamTest() Dim ad As ADODB.Stream Set ad = New ADODB.Stream ad.Open ad.Charset = "utf-8" ad.Position = 0 ad.Type = adTypeBinary Dim b(1 To 2) As Byte b(1) = 209 'D1 b(2) = 143 '8F ad.Write b ad.Position = 0...

What datatype is Value? Is it a string? If not try wrapping it in CStr()

VBA and extended character sets don't mesh very well. This link might help some though. http://social.msdn.microsoft.com/Forums/hu-HU/isvvba/thread/7bb4139b-728a-4da3-a9c0-e1d6661a3075

You need to reference Excel in the application or change this to a late binding model. To reference Excel in the VBA window goto Tools->References find the Microsoft Excel references and add it to your project.

They could hold down the shift key and bypass all those security measures, if you haven't disabled the shift key that is, and even if you have a savy user could turn it back on via code.

Here is some air code (untested) that should do what you want. Sub ExcelPwd(strFullPath As String, pwd As String) Dim oXL As Excel.Application Dim oWBS As Excel.Workbooks Dim oWB As Excel.Workbook Set oXL = New Excel.Application Set oWBS = Excel.Workbooks Set oWB = oWBS.Open(strFullPath)...

Well you could write the actual code, store it in a table, then have access create a new code module and place the code in there then use that code. However if you are doing that it would be nearly as fast or perhaps faster to just write the code into a module to begin with wouldn't it? If...

Well your first example is showing Excel automation code, the workbooks.open code returns a workbook object, use that to Save the file with a password rather than try to use SendKeys. Any expert on here will tell you SendKeys is horribly unreliable.

Stings cannot be set to nothing, only objects/variants. Dim test1, test2 as string results in test1 being a variant, and test2 being a string. To get two string you would need to do, Dim test1 as string, test2 as string. Then both would fail trying to set them to nothing, try...

Don't use sendkeys for this, one of the optional arguments for the workbook object is password, if you assign the password there using the SaveAs method, it will create a version with the password you want.