By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,846 Members | 1,709 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,846 IT Pros & Developers. It's quick & easy.

Run-time error '3251' - While trying to link a table in VB6

richardhodge
P: 2
I am a VB6 database programmer and have run into a small problem. The company I work for primarily uses Microsoft Access 2000 for the database that is the back end for our software. Well the functionality that I am currently working on creates a table in one database and then links it into the primary database that is used by the program to store and retrieve data from.

Here's the problem. I can create the table fine but when I go to link the table I get a run time error as follows:
Run-time error '3251': Operation is not supported for this type of object.

I have looked all over the internet to find a solution to this problem but can't seem to figure it out or figure out a better way of accomplishing what I am trying to do. I'll go ahead and post my code and hopefully someone has an idea on what to fix.

VB6 Code:::::::

Expand|Select|Wrap|Line Numbers
  1. Private Function createlink()
  2.     Dim dbstemp As DAO.Database
  3.     Dim tdf As DAO.TableDef
  4.     Set dbstemp = DBEngine.OpenDatabase(LinkDB.Name)
  5.     On Error Resume Next
  6.     Set tdf = dbstemp.TableDefs(Name)
  7.     If Err.Number <> 0 Then
  8.         On Error GoTo 0
  9.         'the link does not exist yet so create it
  10.         Set tdf = dbstemp.CreateTableDef("ZZZZtesting")
  11.         'Create tabledef defining the link to the table we want
  12.         tdf.Connect = ";DATABASE=" & dpc.DBPath & "\cinfoEIRS.mdb"
  13.         'name of the table in the source DB
  14.         tdf.SourceTableName = "ZZZZtesting"
  15.         'Add the tabledef to the link database
  16.         'On Error Resume Next
  17.         dbstemp.TableDefs.Append (tdf)
  18.         dbstemp.TableDefs.Refresh
  19.     End If
  20.     On Error GoTo 0
  21.  
  22.     Set dbstemp = Nothing
  23.     Set tdf = Nothing
  24. End Function
DBengine is a global variable that points to our workspace.
LinkDB is a global variable that points to the main database that has all of the links in it.
dpc.DBPath is a global class that has the path for all databases

things that I have tried that have not worked:
- put all attributes for the tabledef into one createTableDef command
- creating a new table def and then try appending
- create a new workspace
- Ignoring the error

Everything except ignoring the error breaks at the same point, at the command:
dbstemp.TableDefs.Append (tdf)
And it is always the same error 3251.

Well if anyone has any insight into this I would appreciate it.
Mar 6 '07 #1
Share this Question
Share on Google+
10 Replies


100+
P: 1,646
Although I never use dao or tabledef there is something about this code that does not look right to me. I think you would normally create a tabledef object and then append it to the database. After that you can set its properties (see here). I don't think you can set the tabledef to an existing object and then append it again.

Also your function does not have a return type or value.
Mar 6 '07 #2

Expert 5K+
P: 8,434
Got it!

Change
dbstemp.TableDefs.Append (tdf)
to
dbstemp.TableDefs.Append tdf
Mar 7 '07 #3

vijaydiwakar
100+
P: 579
I am a VB6 database programmer and have run into a small problem. The company I work for primarily uses Microsoft Access 2000 for the database that is the back end for our software. Well the functionality that I am currently working on creates a table in one database and then links it into the primary database that is used by the program to store and retrieve data from.

Here's the problem. I can create the table fine but when I go to link the table I get a run time error as follows:
Run-time error '3251': Operation is not supported for this type of object.

I have looked all over the internet to find a solution to this problem but can't seem to figure it out or figure out a better way of accomplishing what I am trying to do. I'll go ahead and post my code and hopefully someone has an idea on what to fix.

VB6 Code:::::::

Expand|Select|Wrap|Line Numbers
  1. Private Function createlink()
  2.     Dim dbstemp As DAO.Database
  3.     Dim tdf As DAO.TableDef
  4.     Set dbstemp = DBEngine.OpenDatabase(LinkDB.Name)
  5.     On Error Resume Next
  6.     Set tdf = dbstemp.TableDefs(Name)
  7.     If Err.Number <> 0 Then
  8.         On Error GoTo 0
  9.         'the link does not exist yet so create it
  10.         Set tdf = dbstemp.CreateTableDef("ZZZZtesting")
  11.         'Create tabledef defining the link to the table we want
  12.         tdf.Connect = ";DATABASE=" & dpc.DBPath & "\cinfoEIRS.mdb"
  13.         'name of the table in the source DB
  14.         tdf.SourceTableName = "ZZZZtesting"
  15.         'Add the tabledef to the link database
  16.         'On Error Resume Next
  17.         dbstemp.TableDefs.Append (tdf)
  18.         dbstemp.TableDefs.Refresh
  19.     End If
  20.     On Error GoTo 0
  21.  
  22.     Set dbstemp = Nothing
  23.     Set tdf = Nothing
  24. End Function
DBengine is a global variable that points to our workspace.
LinkDB is a global variable that points to the main database that has all of the links in it.
dpc.DBPath is a global class that has the path for all databases

things that I have tried that have not worked:
- put all attributes for the tabledef into one createTableDef command
- creating a new table def and then try appending
- create a new workspace
- Ignoring the error

Everything except ignoring the error breaks at the same point, at the command:
dbstemp.TableDefs.Append (tdf)
And it is always the same error 3251.

Well if anyone has any insight into this I would appreciate it.
Dear why ru using DAO thry to use ADO. Its now the best option databridge
Mar 7 '07 #4

Expert 5K+
P: 8,434
Dear why ru using DAO thry to use ADO. Its now the best option databridge
That does seem to be the consensus of opinion - that ADO is much superior. On the other hand, if you already have something that works, why change it?
Mar 7 '07 #5

100+
P: 1,646
Dear why ru using DAO thry to use ADO. Its now the best option databridge
I agree with Killer on this. I don't think it is useful to recommend completely changing all of the code just because of a bug in one line.
Mar 7 '07 #6

vijaydiwakar
100+
P: 579
See this is not the question of one line bug
if he use ADO then in future also he is able to get the maximum facility given by the ADO. Programming is not the game of just coading its the game of visualization if ur not able to visualise the problem then its of no use.
If M$ alredy given us such advance utilities then why should we go for older one
Mar 7 '07 #7

100+
P: 1,646
See this is not the question of one line bug
if he use ADO then in future also he is able to get the maximum facility given by the ADO. Programming is not the game of just coading its the game of visualization if ur not able to visualise the problem then its of no use.
If M$ alredy given us such advance utilities then why should we go for older one
Because you never ever have a need to change something that works. In this case a part of the code does not work most likely because of the syntax and not because of the type of objects used.
Mar 7 '07 #8

Expert 5K+
P: 8,434
Because you never ever have a need to change something that works. In this case a part of the code does not work most likely because of the syntax and not because of the type of objects used.
Yes, I think you have to consider the amount of effort involved in rewriting an entire application, just because there might be some benefit, some time in the future.
Mar 7 '07 #9

richardhodge
P: 2
Well removing the ( ) from around tdf fixed the problem. The strange thing is that I know I tried that before and it still had problems at the exact same location. Oh well it seems to be working now and I have been testing it for over an hour now with no problems.

As far as switching to ADO that is something that will be happening in the next few months. Personally I prefer ADO, but the company has invested so much time into the current product, which was originally written in MS Access not in vb6 that they did not want to switch to ADO until we convert to VB.net this year.

Oh well I guess that is life.

Thanks again for all of the help. I knew it had to be something stupid, but then again the biggest bugs normally are something stupid.
Mar 7 '07 #10

Expert 5K+
P: 8,434
Well removing the ( ) from around tdf fixed the problem. The strange thing is that I know I tried that before and it still had problems at the exact same location.
Now you know the secret - things don't work unless I tell you to do them. :)

As far as switching to ADO that is something that will be happening in the next few months. Personally I prefer ADO, but the company has invested so much time into the current product, which was originally written in MS Access not in vb6 that they did not want to switch to ADO until we convert to VB.net this year.
Yes, it probably makes sense to do the entire conversion together rather than piecemeal.

Thanks again for all of the help. I knew it had to be something stupid, but then again the biggest bugs normally are something stupid.
That is so true! I think we all run into that problem.
Mar 7 '07 #11

Post your reply

Sign in to post your reply or Sign up for a free account.