This is how to list all Tables and Fields in an Access Database Project (ADP).
Option Compare Database
Option Explicit
Public Sub ListTablesAndFieldsADP()
'---------------------------------------------------------------------
'Reference is needed for: Microsoft ADO Ext. 2.x for DDL and Security
'---------------------------------------------------------------------
Dim cat As New ADOX.Catalog
Dim tbl As ADOX.Table
Dim col As ADOX.Column
Dim fs As Object
Dim output As Object
Set fs = CreateObject("Scripting.FileSystemObject")
Set output = fs.CreateTextFile("c:\Tables_Views_And_Fields.txt", True)
Set cat.ActiveConnection = CurrentProject.Connection
For Each tbl In cat.Tables
If Left(tbl.Type, 6) <> "SYSTEM" Then
output.WriteLine tbl.Name & " (" & tbl.Type & ")"
For Each col In tbl.Columns
output.WriteLine " " & col.Name
Next
output.WriteLine
End If
Next
Set col = Nothing
Set tbl = Nothing
Set cat = Nothing
End Sub
This is how to list all LINKED Tables and Fields in an MS Access Database.
To list Local Tables, remove Len(tdfCurrent.Connect) > 0
Public Sub ListTablesAndFields()
Dim fld As DAO.Field
Dim tdfCurrent As DAO.TableDef
Dim dbCurrent As DAO.Database
Set dbCurrent = CurrentDb
Dim fs As Object
Dim output As Object
Set fs = CreateObject("Scripting.FileSystemObject")
Set output = fs.CreateTextFile("c:\Tables_Views_And_Fields.txt", True)
For Each tdfCurrent In dbCurrent.TableDefs
If Len(tdfCurrent.Connect) > 0 And Left(tdfCurrent.Name, 4) <> "~TMP" Then
output.WriteLine tdfCurrent.Name
For Each fld In tdfCurrent.Fields
output.WriteLine " " & fld.Name
Next
output.WriteLine
End If
Next
End Sub
If you are annoyed at the IIS timeouts when running .NET code via Visual Studio then you'll want you know how to fix that problem!
You can do 1 of 2 things.
* Go to the Application Pool for the Web Application you are working with. Select the Advanced Settings. Set the Ping Enabled property to False. This will allow you debugging to run forever.
* If you prefer to allow IIS to continue the monitoring process then change the Ping Maximum Response Timeout value to something larger than 90 seconds (default value).
If you're getting this error when running backups via Central Admin in SharePoint 2010 then the most likely cause is that the SQL Server, where your Site Collections are, does not have access to the folder you are backing up to. Meaning, your Farm configuration is on multiple machines. Mine is on 2 machines. A Web Front End (where I run the backups from) and a SQL Server machine.
You probably configured the back-up to write to a lettered drive on the Web Front End. Don't worry, I did this too then I realized that it would be best to make a Shared Folder that has the correct permission so thet BOTH machines have access to write to the same location. Then it worked.
Recently I was setting up a new website and came across this error! DON'T be fooled by this error, it does not mean switch on Directory Browsing.
My OS is Windows 2008, IIS 7.0 and the new site is running on .NET 4.0
This is what you need to do to correct the issue.
1.) Run a command prompt as Administrator.
2.) Copy and paste the following text “C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -i”
I hope this helps someone else out there.
Server Error in Application "DEFAULT WEB SITE/TESTSITE"
Internet Information Services 7.0
Error: Access is denied. Verify that either the Default Content Access Account has access to this repository, or add a crawl rule to crawl this repository. If the repository being crawled is a SharePoint repository, verify that the account you are using has "Full Read" permissions on the SharePoint Web Application being crawled.
If you get this error in your Crawl search log then the problem is directly related to the infamous loopback Issue as described below.
You can also read more about this issue on another post located here: http://blog.dafran.ca/post/2011/07/04/Cant-log-into-SharePoint.aspx
The OFFICIAL Microsoft KB article describes the 2 different ways to resolve this issue.
http://support.microsoft.com/kb/896861
The following is copied from the KB link above.
There are two methods to work around this issue, use one of the following methods, as appropriate for your situation.
Method 1: Specify host names (Preferred method if NTLM authentication is desired)
To specify the host names that are mapped to the loopback address and can connect to Web sites on your computer, follow these steps:
- Set the DisableStrictNameChecking registry entry to 1. For more information about how to do this, click the following article number to view the article in the Microsoft Knowledge Base:
281308 (http://support.microsoft.com/kb/281308/ ) Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name
- Click Start, click Run, type regedit, and then click OK.
- In Registry Editor, locate and then click the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
- Right-click MSV1_0, point to New, and then click Multi-String Value.
- Type BackConnectionHostNames, and then press ENTER.
- Right-click BackConnectionHostNames, and then click Modify.
- In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
- Quit Registry Editor, and then restart the IISAdmin service.
Method 2: Disable the loopback check (less-recommended method)
The second method is to disable the loopback check by setting the DisableLoopbackCheck registry key.
To set the DisableLoopbackCheck registry key, follow these steps:
- Set the DisableStrictNameChecking registry entry to 1. For more information about how to do this, click the following article number to view the article in the Microsoft Knowledge Base:
281308 (http://support.microsoft.com/kb/281308/ ) Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name
- Click Start, click Run, type regedit, and then click OK.
- In Registry Editor, locate and then click the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
- Right-click Lsa, point to New, and then click DWORD Value.
- Type DisableLoopbackCheck, and then press ENTER.
- Right-click DisableLoopbackCheck, and then click Modify.
- In the Value data box, type 1, and then click OK.
- Quit Registry Editor, and then restart your computer.
I hope this helps someone out there!
After installing and configuring Search Server Express 2010 on Foundation I was unable to open the Search Service Application I had created in order to configure the crawling. To fix this problem you need to do the following.
- Go To Central Administration
- Under Application Management, click Manage Service Applications
- Highlight the Search Service Application Service that you can't get access to.
- Click on Administrators in the ribbon
- Add your account to the list of Administrators and then check the Full Control Check Box.
- Click OK
Now you should be able to click on the Service Application and Administer it.
Hope this helps!
I had yet another one of those head banging on desk moments yesterday and then discovered the solution today! The problem was that I could NOT log onto SharePoint 2010 Foundation on the machine that was hosting the site (known as the WFE, the Web Front End) using the FQDN (Fully Qualified Domain Name), such as http://mydev.foobar.com. I could, however, log in just fine externally from the domain and even from a different machine in the same domain. I could also log into it on the WFE using the local machine name, like http://MyServer. No matter how hard I tried I could NOT log into the damned SharePoint site using the FQDN on the actual WFE. It prompted me for credentials which I entered correctly but it just kept prompting me.
I even had the network guys set up a zone on the DNS and create A Records etc. But still it wouldn't work. Not only that but the Search Engine Crawl failed for the FQDN and would only work for the Local machine name. So I went on a quest and found the answer. Rather than claim it as my own I have added the link to the article AND also added the resolution steps, just in case the article vanishes from the web! Don't you just hate it when someone posts something and all they do is say the answer is in this link, then the link is so old that it's gone!
http://sharepoint.stackexchange.com/questions/5574/i-cant-login-to-sharepoint-2010-whats-wrong
For the record, this solved my issue on Windows Server 2008 R2 running SharePoint 2010. ALSO AS DC! :) For all you purists!
Disable the loopback check loadTOCNode(2, 'workaround'); Follow these steps:
1. Click Start, click Run, type regedit, and then click OK.
2. In Registry Editor, locate and then click the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
3. Right-click Lsa, point to New, and then click DWORD Value. Type DisableLoopbackCheck, and then press ENTER.
4. Right-click DisableLoopbackCheck, and then click Modify. In the Value data box, type 1, and then click OK.1.2.
RESTART PC!
This explains the reason why! http://www.harbar.net/archive/2009/07/02/disableloopbackcheck-amp-sharepoint-what-every-admin-and-developer-should-know.aspx
The OFFICIAL Microsoft KB article describes the 2 different ways to resolve this issue.
http://support.microsoft.com/kb/896861
The following is copied from the KB link above.
There are two methods to work around this issue, use one of the following methods, as appropriate for your situation.
Method 1: Specify host names (Preferred method if NTLM authentication is desired)
To specify the host names that are mapped to the loopback address and can connect to Web sites on your computer, follow these steps:
- Set the DisableStrictNameChecking registry entry to 1. For more information about how to do this, click the following article number to view the article in the Microsoft Knowledge Base:
281308 (http://support.microsoft.com/kb/281308/ ) Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name
- Click Start, click Run, type regedit, and then click OK.
- In Registry Editor, locate and then click the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
- Right-click MSV1_0, point to New, and then click Multi-String Value.
- Type BackConnectionHostNames, and then press ENTER.
- Right-click BackConnectionHostNames, and then click Modify.
- In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
- Quit Registry Editor, and then restart the IISAdmin service.
Method 2: Disable the loopback check (less-recommended method)
The second method is to disable the loopback check by setting the DisableLoopbackCheck registry key.
To set the DisableLoopbackCheck registry key, follow these steps:
- Set the DisableStrictNameChecking registry entry to 1. For more information about how to do this, click the following article number to view the article in the Microsoft Knowledge Base:
281308 (http://support.microsoft.com/kb/281308/ ) Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name
- Click Start, click Run, type regedit, and then click OK.
- In Registry Editor, locate and then click the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
- Right-click Lsa, point to New, and then click DWORD Value.
- Type DisableLoopbackCheck, and then press ENTER.
- Right-click DisableLoopbackCheck, and then click Modify.
- In the Value data box, type 1, and then click OK.
- Quit Registry Editor, and then restart your computer.
I hope this helps someone out there!
If you've ever configured SharePoint search in 2007 or 2010 then you may have come across this nasty gotcha.
In the SharePoint 2010 world your results would look like this! Nothing! But you know your search engine crawls correctly because you've seen it work and there are no errors in the log!
The reason why this happens is the Default URL is not the one used in the Search crawl. If you don't have this configured correctly then you'll get zero results returned. Not only that but you will see some very weird happenings. When I was playing around trying to understand the problem I did a search and frustratingly got no results so I decided to log in as a different user, and then I saw the results of the search! Wow, that was just silly, so I did another search, thinking it would now work. But no it did not. OK, I thought I would switch back to the previous user again, and guess what! Yes, I saw the results again. But then searching failed if I tried another search. It really stumped me to think that the only way to see search results was to do a search and then log in as a different users. That's what I mean about weird stuff.
The Default URL in this Alternate Access Mapping is used in the Search Configuration. So just following the configuration below is all you need to get results.
This is the Search Service Configuration. Putting it all together will now allow your search to work without even running a crawl! Brilliant. So I thought it would be good to blog about my experience so that others could save their sanity when I almost lost mine...
The following is an explanation of the 2 types of Authentication. This is well documented on the web!
Classic Mode: This is nothing but Windows Authentication. If any web application is created with Classic Mode Authentication then it cannot applicable to configure forms based authentication. That is basically it.
Claims Based: In SharePoint 2010 for a web application we can enable both windows AND forms authentication. In earlier implementation to do this, we have to create two web applications which has different zones and different authentication. But, with the new claims based authentication a single application can have the capability to configure both windows and forms under single URL. All this is possible because of the authentication framework is built on Microsoft Identify Foundation, and it uses “Geneva” framework to handle this authentication.
Convert from Classic Windows to Claims Based Authentication: To configure a Windows Authentication application to use Forms Based Authentication then you can convert from Classic Mode to Claims Based. But, there is no UI exist for doing this conversion. The only way around is through PowerShell.
WARNING! This cannot be UNDONE!
At the PS Prompt Type the following commands and press enter after each one.
$app = get-spwebapplication "http://<your site's URL>"
$app.useclaimsauthentication = "True"
$app.Update() Don't forget the brackets!
IMPORTANT: If an application is created using Claims Based Authentication and if you want to convert to Classic Mode then it is not possible either through the UI or through PowerShell.