I am trying to migrate an access database from 2000 to 20007 version. I have two .mdb files one used as a front end and the other containing only the back end tables. I performed all the necessary initialization for the migration like export of table, extension with .accd, etc.. But when i execute the following code , i get an error " Microsoft office cannot find the input table or query . Check spelling and so".
set Db=currentDb
SQLText ='some sql query'
Db.OpenRecordset(SQLText, dbOpenDynaset)
When i tried to output the value of Db with a msgbox (MSgbox Db), it shows the message "ABC, type mismatch", where ABC is the function name. But, Msgbox Db.name showing the correct database name. But, the same code has been running fine on the older version.
Please help me on this
Okay, you do not have to "migrate" to a different version persay. You only have to import everything from an MDB to ACCDB file. That is all. Scratch whatever you have done, start afresh.
Create a new "empty" accdb file, then using the options under
External Data-> Import/Link From Access. Select the Front End Access
file. Use the Option IMPORT Forms, Report etc., select all Forms, Reports, Queries, Mods then click OK. This
will import all objects.
Create a new "empty" accdb file, then using the options under
External Data-> Import/Link From Access. Select the Back End Access file. Use the Option IMPORT Forms, Report etc., select all tables and click OK. This will import all the tables over to the new file.
Now open up your new "front end" (the one with accdb extension). Under External Data -> Import/Link. Select the new "back end" (the one with the accdb extension). Use the Link to the Data Source option. Then select all tables and click OK.
Now perform a Compact & Repair, follow it with a Compile of the VBA code.
The whole strategy will fail if you have a backend DB in a different platform like SQL or Oracle.
Related
In our backend project, we have some features that allows to export files to xlsx.
We have done some tests locally and everything is working fine.
However, I deployed the app in an Azure App Service and some of the exports (not all) are not working fine.
I deployed backend (PHP), frontend (React) and database (MySQL) in Azure. I copied the information of the local DB to the DB deployed in azure (just because we don't wanna waste time with the data).
In the backend project, we are using Laravel with Maatwebsite for the features related to the exports. I created a class that implements FromQuery, WithHeading and ShouldAutoSize and that has construct, query and headings functions. Next, in a Controller, I use this structure to get the file:
public function functionName(Request $request){
$fileName= 'name'.time().'.xlsx';
return (new ClassThatHasTheLogicOfExporting($request->all()))->download($fileName);
}
All my exports works like that, but I'm getting the following error in some of them:
"Excel cannot open the file because the file format or file extension is not valid"
When I try to open the file.
I've been reading about the issue and some people says that I should use ob_start() (at the beggining of the class) and ob_end_clean() (just before exporting the file) but when I do this, I get a 404 error in the web app.
A curious thing is that when I add a filter to the data for exporting (for instance, downloading only the data of people in a specific city) (I can do it in the frontend app), the file opens without errors.
With this strategy, I've achieved downloading all the data in separate groups, so I don't think that the issue is related to special characters in the data.
Does anybody have any suggestion?
I'm using maatwebsite/excel 3.1 and PHP 8 with Laravel 8
I believe the error statement correctly suggests the error is being caused due to an invalid extension. Don’t worry there are several workarounds to this, I am sharing them below:
Method 1 – Change the Default File Format to Save Excel Workbooks
In Excel 2007, click the ‘Microsoft Office’ button and then ‘Excel Options’. In Excel 2010 and higher versions, click File > Options.
Select the Export option.
Select the Change File Type option.
Change the file extension, and then click Save As.
Method 2 – Recover Unsaved Workbook
Go to File and select the Info option.
Under Manage Versions, select ‘Recover Unsaved Workbooks’ op
If MS Excel has unsaved files then, it will list them. You can open and save it.
Method 3 – Use the' Open and Repair' Feature of MS Excel
Open MS Excel application.
Go to File and select the Open option.
Select the corrupt file and choose the Open and Repair option.
You can also check this forum:
https://social.technet.microsoft.com/forums/office/en-US/63020ccc-51d7-46d9-b956-121c0e6efcc8/excel-file-error-the-file-format-and-extension-dont-match?forum=Office2016ITPro
Best Regards,
Steve
you can add the below
if (ob_get_length() == 0 ) {
ob_start();
$response = Excel::download(new KingdomsExport, 'kingdoms.xlsx',\Maatwebsite\Excel\Excel::XLSX);
return $response;
}
Step 1:
I went to the tools menu in origin oracle pl sql then choose export user object and select that file i need to convert to destination database like view and functions and packages etc...
Step 2 :
after that i went to destination database and open new command window and paste that file create in step1.
after that i get this error for many objects:
ora00900 : invalid sql statement
how can i import that file created with pl/sql export user object?
If you are using Oracle SQL Developer and trying to export DDL and Data, make sure that selected format is "insert". Other formats are not applicable to run as SQL statement.
If your goal is full export consider using Oracle DataPump: https://docs.oracle.com/en/database/oracle/oracle-database/19/sutil/oracle-data-pump-overview.html
I've create a SQL Server Database Project and imported my database. I've got a few static data tables that I want to recreate every time it's redeployed, so these get recreated as part of the post deployment script.
To ensure this drops and recreates them I've changed these static data tables to have a build action of 'None' so they are dropped as part of the build and only recreated as part of post deployment steps.
My problem is that I have a view that references these tables. Obviously this shows syntax errors as the tables are no longer part of the build as their build action is 'None'. My workaround was to try and create the view also as part of the post deployment script. I do this with the following code:
:r .\PostDeploymentScripts\Views\myView.sql
The actual script looks like this:
CREATE VIEW [CompTotalByType] AS
SELECT
c.Id,
t.id AS TypeId,
SUM(c.total) AS CompTotal,
FROM CompNumber c
INNER JOIN Type t
ON t.ProdId = c.ProdId
GROUP BY
c.Id,
t.id
However, now I get a syntax error under 'CREATE VIEW' as follows:
Severity Code Description Project File Line Suppression State
Error SQL72007: The syntax check failed 'Incorrect syntax near CREATE.' in the batch near:
'CREATE VIEW [CompTotalByType] AS' ....path name....
However, when I put this code into SSMS it has no syntax errors. What's causing this?
I found the answer here: SQL72007: The syntax check failed 'Unexpected end of file occurred.' in batch near :
It was the second answer that said you needed to add a 'GO' to the previous script. This makes sense as the CREATE VIEW needs to be in its own batch. So I added a 'GO' to the bottom of my previous script before creating the view and that fixed it.
How many static tables are you trying to recreate? I have a similar situation, but what I do instead is create 'MERGE' scripts using a stored procedure on Github called sp_generate_merge. Then I simply include those scripts within the project under a 'Scripts' folder and call them within the post-deployment script. That way you don't have to drop/create them, and your view and tables can be included in the build.
However, if you'd like to keep it the same - it seems that the other user is correct in saying that you need to add 'GO' before 'CREATE VIEW'.
I inherited a legacy system using Crystal Reports in VS.NET pulling info from an Oracle11g DB.
The database fields are in "REPORT_DATA", I updated the stored procedure which the code is querying to add a field, however I cannot see that new field in the field explorer.
When I click on "Verify Database" and manage to log into the DB I get a "Remove Table" prompt - "The database table "REPORT_DATA" cannot be found. Proceed to remove this table from the report?"
Of course, there is no REPORT_DATA table and there never was.
When I preview the report or put it on the server it works, so there is some behind-the-scenes magic which I don't understand.
Figured it out.
I had to highlight the server name in the “Current Data Source” area and the name of the server in the “Replace With” area on the Set Datasource Location window. Then click the “Update” button.
Since the report wasn't built on my machine it had to be reconfigured - can't figure out why it still connected to the DB when previewing though.
When adding in tables from SQL Server to a dbml, it will drop the 's' off of the table name. One example: when adding the table 'Alias' it will change the name to 'Alia'. Is there any way to prevent this from happening?
Method of adding tables:
1) Connect to database in the Server Explorer Tab
2) Open tables folder
3) Select all the tables and drag them to the open dbml window
If you are using entity framework, and adding tables via the update wizard, there is a checkbox which says "Pluralize or singularize generated object names":
You can uncheck that and it will leave your table names alone.
Update: looks like you are drag/dropping to DBML, try this link:
Linq to SQL: How do I stop the auto generated object name from being renamed?